[10726] in bugtraq
Windows NT 4.0, 95, 98 (?) networked PRN flaw
daemon@ATHENA.MIT.EDU (STEVENS, Eric)
Sun Jun 6 13:26:04 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <AA1266092DDDD11197A20000F84A81B801EB64C3@clvex04.clv.rpr.rp>
Date: Fri, 4 Jun 1999 08:20:16 -0400
Reply-To: "STEVENS, Eric" <Eric.Stevens@RP-RORER.COM>
From: "STEVENS, Eric" <Eric.Stevens@RP-RORER.COM>
To: BUGTRAQ@NETSPACE.ORG
-----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.
Explanation and flaw follow.
First, the explanation (for those of you who are familiar with the
command line use of prn, please skip to the flaw)
Old style MS-DOS command line-ing would allow you to do the following
to print your autoexec file:
C:\>copy autoexec.bat prn
what this actually does is redirect the contents of autoexec.bat to
the port LPT1. So, as stated in the first sentence, in an effort to
preserve this feature, Microsoft will not allow you to create any file
or directory whose name prior to the extension is exactly PRN.
Now the flaw:
Although you cannot create a local file whose name is PRN, you can,
however, jump onto a networked server (suppose it's name is
\\whatever) and create (in any directory that you have creatable
permissions) any file or directory named PRN.xxx (again, xxx stands
for any extension). The server must be accessed by it's \\ notation,
you cannot do this if you map \\whatever\anydir to a drive (such as
w:), then go to w:\ and try to create the file, in that case your
machine's name parser blocks you.
Ok, so that doesn't seem so bad, but the real issue is that the
directory you've just created is non-removable for as long as it
posesses that name. So let's try to rename the file... oops, can't do
that, we get an access violation. Next, let's try mapping
\\whatever\anydir to w:\ again. I go to my new W drive and try to
rename the file, I get the error "Cannot rename prn: A file with the
name you specified already exists. Specify a different filename."
Ooooookaaaaay. Frustrated now, I try to delete the file. Oops, now
it tells me "Cannot delete prn: The parameter is incorrect." Well,
what about that file/directory I've created with the name PRN.xxx?
That one vanishes with no problem, but only when the server is
referenced in the \\whatever fashion. When I try to delete this
PRN.xxx file from my new W: drive, all it does is lock up my window
with a nearly endless hourglass. Finally, ten minutes later, I'm told
"Cannot delete file: File system error (1026)." But this only occurs
after I've renamed the parent directory. The error that is reported
has nothing to do with the file PRN.xxx, but instead with the fact
that the file upon which it was trying to do a delete operation
dissapeared between when the delete was initiated and when it was
finished. Note that PRN.xxx acts somewhat differently than PRN alone.
The next step is to try to delete the parent directory. This does not
work! PRN still gives access violations, and so the parent directory
is locked in place. So how much harm can this REALLY be? So I've got
a few empty files and directories that are undeletable. Well, if in
stead of just creating a new directory, I copy a large directory to
the server, say c:\winnt, or perhaps c:\program files, then rename it
to prn, now I've just created half a gig or more (depending on how
malicious I am) of un-reclaimable server hard drive consumption. This
directory cannot be browsed! It has become a sore on the surface of
this hard drive.
Well, remember con? The virtual file that was like prn, except that
instead of echoing to LPT1, it echoes to the screen. I try to
recreate this whole process with con, but the server is much too smart
for that, it yells at me and tells me "Cannot create or replace file:
The filename you specified is invalid or too long. Specify a
different filename."
I don't know, but I suspect that there exist utilities that would
catch this filename's invalidity, and do something about it. Norton
Disk Doctor is usually pretty good about those kinds of things.
Unfortunately, I don't have local access to the servers I have
available to create this flaw on, so I cannot test that. If someone
can test that on various workstations and servers, I'd be interrested
to know if Norton can do this. Please put your new PRN directory/file
in a place that you don't care if it resides there forever.
This flaw seems to lend itself to a disk-consuming virus, one that
creates \\127.0.01\anydir\hahaha.tmp and dumps useless garbage in it
until it receives the TERM signal at which point it renames this file
to PRN. Next time it is started this virus could create a subdir
called hahaha and repeat the process there.
This was tested on Windows NT workstation 4.0 SP3 creating PRN's on
Windows's NT Server 4.0 SP?.
_____ ,----+ _________________________________ + _____
____ / __________ eric stevens ___________ \ ____
___ /--+ _____ eric.stevens@rp-rorer.com _____ \ ___
__ / ____ rpr graphics asp design team _____ \ __
_ `----+ x-eric-conspiracy: there is no conspiracy + _
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0.2 for non-commercial use <http://www.pgp.com>
iQA/AwUBN1fEnL2zm+J5R2AnEQJwjgCg5EH7v6mFSfU7ZIt2hrZVIWD1htcAn3Ip
+4OSrPVSx+zhGJfiktWZAKrL
=1lyf
-----END PGP SIGNATURE-----
