I've recently started migrating a customer's network from LPR-only to
printer connections. Now, printers are created on the Windows NT servers and
workstations only connect to them - thus eliminating local printers on
workstations.

Having a user double-click on a server's printer from a workstation wouldn't
create a printer connection unless the driver for the printer was already
installed on the workstation, because, apparently, a user can't install a
driver. "Of course, silly me. Otherwise I could easily compromise the
system." I said to myself. So, I started looking for a quick method for
installing printer drivers on 8000 workstations. Then, by suggestion of a
colleague, I tried con2prt, from the ZAK. Amazingly, the use of con2prt
allowed *any* user to install printer drivers on workstations.

What's the issue? Let's assume that, once the spooler runs under the
LocalSystem context, the drivers do, too. So, I imagined the following
scenario: I create a printer driver that executes some malevolent code every
time someone prints to it. I can install it on one of my machines and then,
from a the workstation I want to take over - and where I only have User
privileges - I use con2prt to install my driver. Then, by printing something
to it, I will trigger the code - that will execute under LocalSystem. Ouch.

If, on the contrary, the drivers run under the logged on user context, let's
imagine a different scenario: I make one of the files for the driver
overwrite a file for another printer's driver - maybe the default printer.
Now, I just need to have an administrator log on the workstation and print
something.

I can't believe this is a real issue. I'm just posting this because I can't
believe my eyes. Con2prt is a mature and widespread utility, and it's still
used on W2K's ZAK; if it showed any potential for security exploits, I
suppose it would have been fixed - or the system API that it calls. Or am I
being too optimistic?

Paulo Meireles
MCSE

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]