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

From: STEVENS, Eric (Eric.Stevens@RP-RORER.COM)
Date: Fri Jun 04 1999 - 05:20:16 PDT

  • Next message: Valentin Perelogin: "Remote Exploit (Bug) in OmniHTTPd Web Server"

    -----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-----
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:48:17 PDT