windows.prn.flaw.txt

1999-08-17T00:00:00
ID PACKETSTORM:11849
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                        
                                            `Date: Fri, 4 Jun 1999 08:20:16 -0400  
From: "STEVENS, Eric" <Eric.Stevens@RP-RORER.COM>  
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 <http://www.pgp.com>  
  
iQA/AwUBN1fEnL2zm+J5R2AnEQJwjgCg5EH7v6mFSfU7ZIt2hrZVIWD1htcAn3Ip  
+4OSrPVSx+zhGJfiktWZAKrL  
=1lyf  
-----END PGP SIGNATURE-----  
  
------------------------------------------------------------------------  
  
Date: Sun, 6 Jun 1999 11:45:43 -0700  
From: David LeBlanc <dleblanc@MINDSPRING.COM>  
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 <tez@INTERFACE.ON.CA>  
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 <nick@virus-l.demon.co.uk>  
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 <tez@INTERFACE.ON.CA>  
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 <jens@PINGUIN.CONETIX.DE>  
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" <bbl@AVENIR.NO>  
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 <jogata@NODC.NOAA.GOV>  
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 <jogata@nodc.noaa.gov> 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 <ajm@ISLANDCORP.COM>  
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 <mouse@RODENTS.MONTREAL.QC.CA>  
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 <Lyndon.Nerenberg@MESSAGINGDIRECT.COM>  
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 <franklin@ARCH.ETHZ.CH>  
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" <Eric.Stevens@RP-RORER.COM>  
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 <aleph1@UNDERGROUND.ORG>  
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 <jogata@NODC.NOAA.GOV>  
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 <jogata@nodc.noaa.gov> National Oceanographic Data Center  
You can't step into the same river twice. -- Herakleitos  
  
`