Date: Fri, 4 Jun 1999 08:20:16 -0400 From: "STEVENS, Eric" To: BUGTRAQ@netspace.org Subject: Windows NT 4.0, 95, 98 (?) networked PRN flaw -----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 iQA/AwUBN1fEnL2zm+J5R2AnEQJwjgCg5EH7v6mFSfU7ZIt2hrZVIWD1htcAn3Ip +4OSrPVSx+zhGJfiktWZAKrL =1lyf -----END PGP SIGNATURE----- ------------------------------------------------------------------------ Date: Sun, 6 Jun 1999 11:45:43 -0700 From: David LeBlanc To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw 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 ------------------------------------------------------------------------ Date: Sun, 6 Jun 1999 15:23:53 -0400 From: Terry Milnes To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw Eric, You can however rename the file the same way you created it, and then delete it in any manner you would normally do. NT Server 4.0 sp4 > 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. > ------------------------------------------------------------------------ Date: Mon, 7 Jun 1999 16:49:24 +1200 From: Nick FitzGerald To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw > [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 Whilst I'll assume that this is true (too much trouble to test it and it sounds kosher), it is overkill for files. Simple DEL CO? will nuke CON (and any other matching file). MS-created GUI interfaces (File Manager, Explorer) tend to get in the way. In the case of directories it might not be so easy... Regards, Nick FitzGerald ------------------------------------------------------------------------ Date: Mon, 7 Jun 1999 08:16:02 -0400 From: Terry Milnes To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw Well I better clarify here, I did test this but misunderstood the initial post, I started with Rm -d prn on the directory, and of course it did delete, tried Rm prn on a file, it deleted too, I quickly scanned the message, thought it said something else so played with a couple of other ways and posted.... So all of you out there who are wondering what is different about my NT, nothing is different just the operator. Terry... "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. > Explanation and flaw follow. > > First, the explanation (for those of you who are familiar with the ------------------------------------------------------------------------ Date: Mon, 7 Jun 1999 20:06:55 +0200 From: Jens Benecke To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw On Fri, Jun 04, 1999 at 08:20:16AM -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. > Explanation and flaw follow. (...) > 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 I get exactly the same error when trying to rename/move/open/copy a file that contains UNIX umlauts, when SAMBA is serving that file to any Windows flavor. This seems to be a Windows problem, a 'sed' script remaps all the "bad" characters and all went well (ok, now you don't see them on UNIX but WTH...) This was reproduced on all current Windows versions and a Linux box running Samba. I think there is already a codepage remapping patch available for Samba that fixes this. > 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. The server should at least be capable of removing 'anything' locally. If not, this could be a really serious bug, imagine NT, not having user quotas, as a $HOME server to a couple bad boys. -- _ciao, Jens_______________________________ http://www.pinguin.conetix.de Anyone comfortable with using Linux shall use it. | "I'm afraid Linux has a Anyone wanting to tell other people what they | year-429496 problem" should be using can go work for Microsoft. | -- Kernel mailing list ------------------------------------------------------------------------ Date: Tue, 8 Jun 1999 16:16:55 +0200 From: "[iso-8859-1] Bjørnar B. Larsen" To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw Nick FitzGerald wrote: > Simple DEL CO? will nuke CON (and any other matching file). > MS-created GUI interfaces (File Manager, Explorer) tend to get in > the way. > > In the case of directories it might not be so easy... Microsoft's got a KB article on this, see Q120716 ( http://support.microsoft.com/support/kb/articles/Q120/7/16.asp ) :-) bjornar ------------------------------------------------------------------------ Date: Tue, 8 Jun 1999 14:13:36 -0400 From: Jefferson Ogata To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw Along similar lines, I've discovered (through bad code) that certain NFS implementations will allow you to create files with a / in their names. Obviously, it's pretty difficult to get rid of these files after the fact. As far as I've been able to tell, all UNIX system calls parse paths, and will always treat a path like "a/b" as the file "b" in the directory "a", rather than the file "a/b" in the current directory. Not even rm -r on the directory could clean this up. The only way I've found to get rid of these files is by using the same NFS client code that was used to create them (whew!). Note that this code has to be "buggy" in the sense that it doesn't correctly parse paths. Yes, I did make a mistake. Erp! This could be used to create a pretty nasty DoS, if an attacker has write access to your NFS filesystem (this is more common than you might think). I wonder what would happen if I created a file called "/etc/passwd" in the current directory... probably nothing. But who knows? -- Jefferson Ogata National Oceanographic Data Center You can't step into the same river twice. -- Herakleitos ------------------------------------------------------------------------ Date: Tue, 8 Jun 1999 17:38:11 -0300 From: Aj Mirani To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw At 08:20 AM 04/06/99 -0400, you wrote: So you create a file like this: copy xxx.tmp \\Orbitor\Incoming\prn.xxx removing it is as easy as: del \\Orbitor\Incoming\prn.xxx This was tested on NT Workstation SP4 >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. -- Aj Mirani - ajm@islandcorp.com Network Administrator Island Corporation #10-3000 Landgstaff Rd Concord, ON L4K 4R7 Tel: (905)761-1655 ------------------------------------------------------------------------ Date: Thu, 10 Jun 1999 10:24:48 -0400 From: der Mouse To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw > Along similar lines, I've discovered (through bad code) that certain > NFS implementations will allow you to create files with a / in their > names. > The only way I've found to get rid of these files is by using the > same NFS client code that was used to create them (whew!). Note that > this code has to be "buggy" in the sense that it doesn't correctly > parse paths. I don't see how that follows. Not all OSes use / as a pathname component separator. (I think the Mac uses :, for example.) For that matter, it's not clear to me that all OSes use file names that are formed - or partially formed - by concatenating component strings with a distinguished separator character. (As a simple example of what else could be used, consider a length-and-contents list of length-and-contents components.) I also don't *think* the NFS spec forbids slashes in pathname components, at least not back when I did my NFS implementation - RFC1094 doesn't seem to, anyhow - which means that an NFS server that *doesn't* allow this is arguably buggy. (For that matter, I don't think NULs are forbidden either.) And there's no error code for "everything looks fine except the "filename" you specified is unacceptable to me"; the only one I can see that could reasonably be used is NFSERR_IO, and that's a bit of a stretch. Put these together and the conclusion I come to is that the only reason this sort of problem hasn't been seen more is that all NFS implementations (except for a set of measure zero :) are on UNIXoid systems and hence are "well-behaved" with respect to slashes and NULs and the like. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ------------------------------------------------------------------------ Date: Wed, 9 Jun 1999 12:47:10 -0600 From: Lyndon Nerenberg To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw > I wonder what would happen if I created a file called "/etc/passwd" in > the current directory... probably nothing. But who knows? If you created it in, say, /var/tmp, and the system had a root-run cron job that did 'cd /var/tmp; find . -mtime +7 -print | xargs rm -f', things would get interesting. A quick scan through ufs_readdir() (in FreeBSD-current) indicates it will return the file name, slashes and all. Thus, anything calling unlink() inside of a readdir() loop would be in for one hell of a surprise. -- The two most common elements in the universe are Hydrogen and stupidity. -- Harlan Ellison ------------------------------------------------------------------------ Date: Thu, 10 Jun 1999 08:51:49 +0200 From: Neil Franklin To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw Jefferson Ogata wrote: > > The only way I've found to get rid of these files is by using the same NFS > client code that was used to create them (whew!). I would actually call this an nfsd Bug, that it accepts such paths. Servers should not trust clients. > This could be used to create a pretty nasty DoS > I wonder what would happen if I created a file called "/etc/passwd" in > the current directory... probably nothing. But who knows? Annother DoS possibility: your backup software may crap on backing up such a file, or even worse backup flawlessly and then crap on restoring >from an tape with such an file. Old story: A friend of mine, years ago (so I can not remember the details), had a Sun with an Appletalk deamon, which somehow managed to bypass the "/" checks in the kernal. Macs allow "/" im Filenames, so such a file got created. Whatever backup software he used crapped on reading back the tape with these filenames in them. As you have had such a file on your system, I would recommend an test restore of the directory involved. -- Neil Franklin, Sysadmin, Architecture & CAAD, ETH Zuerich franklin@arch.ethz.ch.remove http://caad.arch.ethz.ch/~franklin/ ------------------------------------------------------------------------ Date: Wed, 9 Jun 1999 15:25:23 -0400 From: "STEVENS, Eric" To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw Well observed, but as I stated in my original email, prn.xxx can be deleted in this fashion while prn with out an extension is quite stubborn about it's place in the directory structure. It would seem that a different line of code in the name parser declares prn to be bad than the one that declares prn.xxx to be bad. The line to catch prn in a network path exists in the del parser, but no other parser, wile the line to catch prn.xxx does not exist in any parser. I've recieved several emails suggesting using the same method of deleting the file as I used to create it, and each of them has actually used a prn.xxx file instead of a prn file. Please take note that they are distinctly different, prn.xxx has successfully been removed using the same method as creation while prn does not delete! > -----Original Message----- > From: Aj Mirani [SMTP:ajm@islandcorp.com] > Sent: Tuesday, June 08, 1999 4:38 PM > To: BUGTRAQ@netspace.org > Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw > > At 08:20 AM 04/06/99 -0400, you wrote: > So you create a file like this: > copy xxx.tmp \\Orbitor\Incoming\prn.xxx > > removing it is as easy as: > del \\Orbitor\Incoming\prn.xxx > > This was tested on NT Workstation SP4 > > >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. > > > -- > > Aj Mirani - ajm@islandcorp.com > Network Administrator > Island Corporation > #10-3000 Landgstaff Rd > Concord, ON L4K 4R7 > Tel: (905)761-1655 _____ ,----+ _________________________________ + _____ ____ / __________ eric stevens ___________ \ ____ ___ /--+ _____ eric.stevens@rp-rorer.com _____ \ ___ __ / ____ rpr graphics web design team _____ \ __ _ `----+ x-eric-conspiracy: there is no conspiracy + _ ------------------------------------------------------------------------ Date: Thu, 10 Jun 1999 12:11:19 -0700 From: Aleph One To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw This is a bug in the NFS server implementation. The NFS protocol does not limit the character set that can be used in filenames, but the NFS server MAY restrict it based on the native filesystem it uses to store the files. >From RFC 1813: 4.6 File name component handling Server implementations of NFS version 3 protocol will frequently impose restrictions on the names which can be created. Many servers will also forbid the use of names that contain certain characters, such as the path component separator used by the server operating system. For example, the UFS file system will reject a name which contains "/", while "." and ".." are distinguished in UFS, and may not be specified as the name when creating a file system object. The exact error status values return for these errors is specified in the description of each procedure argument. The values (which conform to NFS version 2 protocol server practice) are not necessarily obvious, nor are they consistent from one procedure to the next. -- Aleph One / aleph1@underground.org http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 ------------------------------------------------------------------------ Date: Thu, 10 Jun 1999 15:04:53 -0400 From: Jefferson Ogata To: BUGTRAQ@netspace.org Subject: Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw der Mouse observed: > I also don't *think* the NFS spec forbids slashes in pathname > components, at least not back when I did my NFS implementation - > RFC1094 doesn't seem to, anyhow - which means that an NFS server that > *doesn't* allow this is arguably buggy. (For that matter, I don't > think NULs are forbidden either.) And there's no error code for > "everything looks fine except the "filename" you specified is > unacceptable to me"; the only one I can see that could reasonably be > used is NFSERR_IO, and that's a bit of a stretch. The following is from RFC 1813 (NFS Version 3 Protocol). Note paragraph 5 in particular. I haven't checked the version 2 spec for similar content. 3.2 General comments on filenames The following comments apply to all NFS version 3 protocol procedures in which the client provides one or more filenames in the arguments: LOOKUP, CREATE, MKDIR, SYMLINK, MKNOD, REMOVE, RMDIR, RENAME, and LINK. 1. The filename must not be null nor may it be the null string. The server should return the error, NFS3ERR_ACCES, if it receives such a filename. On some clients, the filename, ``'' or a null string, is assumed to be an alias for the current directory. Clients which require this functionality should implement it for themselves and not depend upon the server to support such semantics. 2. A filename having the value of "." is assumed to be an alias for the current directory. Clients which require this functionality should implement it for themselves and not depend upon the server to support such semantics. However, the server should be able to handle such a filename correctly. 3. A filename having the value of ".." is assumed to be an alias for the parent of the current directory, i.e. the directory which contains the current directory. The server should be prepared to handle this semantic, if it supports directories, even if those directories do not contain UNIX-style "." or ".." entries. 4. If the filename is longer than the maximum for the file system (see PATHCONF on page 90, specifically name_max), the result depends on the value of the PATHCONF flag, no_trunc. If no_trunc is FALSE, the filename will be silently truncated to name_max bytes. If no_trunc is TRUE and the filename exceeds the server's file system maximum filename length, the operation will fail with the error, NFS3ERR_NAMETOOLONG. 5. In general, there will be characters that a server will not be able to handle as part of a filename. This set of characters will vary from server to server and from implementation to implementation. In most cases, it is the server which will control the client's view of the file system. If the server receives a filename containing characters that it can not handle, the error, NFS3ERR_EACCES, should be returned. Client implementations should be prepared to handle this side affect of heterogeneity. -- Jefferson Ogata National Oceanographic Data Center You can't step into the same river twice. -- Herakleitos