[10732] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw

daemon@ATHENA.MIT.EDU (David LeBlanc)
Sun Jun 6 15:31:13 1999

Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <3.0.3.32.19990606114543.0376aca0@mail.mindspring.com>
Date: 	Sun, 6 Jun 1999 11:45:43 -0700
Reply-To: David LeBlanc <dleblanc@MINDSPRING.COM>
From: David LeBlanc <dleblanc@MINDSPRING.COM>
X-To:         "STEVENS, Eric" <Eric.Stevens@RP-RORER.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <AA1266092DDDD11197A20000F84A81B801EB64C3@clvex04.clv.rpr.r p>

At 08:20 AM 6/4/99 -0400, STEVENS, Eric wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1

>I suppose that, in an effort to maintain reverse compatibility with
>old MS-DOS command line gurus, you cannot create a file or directory
>named PRN.xxx where the xxx is replacable with any extension.

[lots and lots trimmed]

I first encountered this a long time ago when I inadvertantly created a
file named 'CON'.  Went round and round through most of the snippage trying
to remove it.  What it boils down to is that anything that has the same
name as a DOS device (which is a link to an actual device, just like you're
used to seeing in /dev) is going to resist getting deleted and moved.

The solution is to use a POSIX utility to remove it.  The POSIX subsystem
is blissfully unaware of DOS, and PRN, CON, LPT1 and the like mean nothing
to it.  So if you'd just tried rm PRN.xxx, then it would have gone away.

It's kind of amusing to me that the solution is to use a UNIX CLI utility -
the people from a DOS background never think of it, and the people from a
UNIX background don't usually think to try UNIX tools to fix an NT problem 8-)

There's a KB article on this one -
http://support.microsoft.com/support/kb/articles/Q120/7/16.asp

I've found that searching the knowledge base can sometimes save me a lot of
time.

BTW, you can get a POSIX version of rm in the NT Resource Kit.  I believe
there are a number of other POSIX shells and subsystems available, some of
which are free.  If you don't have one, it is also pretty easy to create
one using VC++ - creating POSIX apps is documented, so int main(int argc,
char* argv[]){return unlink(argv[1]);} will do in a pinch.  Note that some
ports of rm and other UNIX tools do run in the Win32 subsystem, and so may
not remove it.  I haven't experimented with it, but I would suspect that
various absolute UNC paths may well nuke such files - passing something
along the lines of \\.\c$\temp\prn.xxx to DeleteFile() might also do it.
\\?\c:\temp\prn.exe may also work, since it says in the notes to
CreateFile() that this turns off path parsing.

Also, if someone decides to annoy you by creating these, check the owner of
the file - should lead to the culprit.  If I caught someone doing this to
me, I'd set their shell to notepad, or put shutdown.exe in their logon
script >8-) - something to get the idea across that playing games with the
admin isn't a great idea...


David LeBlanc
dleblanc@mindspring.com

home help back first fref pref prev next nref lref last post