COMMAND

    kernel (networked PRN flaw)

SYSTEMS AFFECTED

    Windows NT 4.0, 95, 98 (?)

PROBLEM

    Eric Stevens found following.  Guess is, 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.  We go to  my new W drive and  try to rename the file,  and
    get  the  error  "Cannot  rename  prn:  A  file  with the name you
    specified  already   exists.   Specify   a  different   filename."
    Ooooookaaaaay.   Frustrated  now,  let's  try  to delete the file.
    Oops,  now  it  tells  me  "Cannot  delete  prn:  The parameter is
    incorrect."  Well,  what  about  that file/directory we'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 you 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, you'll be  told "Cannot delete  file:
    File  system  error  (1026)."   But  this  only  occurs  after you
    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?   Let's  get  a  few  empty  files  and  directories  that are
    undeletable.  Well, if in stead of just creating a new  directory,
    you copy a large directory to the server, say c:\winnt, or perhaps
    c:\program files, then rename it to prn, now you just created half
    a  gig  or   more  (depending  on   how  malicious  one   is)   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.   While trying  to recreate  this whole  process with con,
    the server  is much  too smart  for that,  it yells  at and  tells
    "Cannot create  or replace  file:   The filename  you specified is
    invalid or too long.  Specify a different filename."

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

SOLUTION

    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.  There's a KB article on this one -

        http://support.microsoft.com/support/kb/articles/Q120/7/16.asp

    BTW, you can get a POSIX version of rm in the NT Resource Kit.  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.
    You can however rename the file  the same way you created it,  and
    then delete it in  any manner you would  normally do.  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...