COMMAND

    kernel

SYSTEMS AFFECTED

    Mostly Windows, but see whole text

PROBLEM

    Huh, this was compiled by big number of posts.  Originally it  was
    brought to public by Scott Campbell.  While he was testing another
    buffer overflow, he created a long filename called  "testfile.txt"
    (note the chr(160)'s at the  end) It is 235 characters  in length.
    After creating  it on  desktop, right  click on  it; explorer will
    crash  saying  it  caused  an  illegal  operation.  Easiest way to
    reproduce this is  to create the  long filename is  right click on
    the desktop filename,  go to 'rename',  put space and  chr(160) at
    the end.

    The same was tested under Windows NT 4 Workstation SP3, except the
    file name  length was  only 225  bytes, called  "hello.txt(lots of
    spaces)(chr(160))", and Explorer crashed  as well here.   Clifford
    Hammerschmidt  posted  following  perl  script  will  create a 250
    character file  that will  crash WinNT  (service pack  3) explorer
    when right-clicked on:

        $fn = 'A' x 250;
        open (FH,">$fn") or die ":$!\n";
        print FH "it worked?";
        close FH;

    You may have to create the file inside a subdirectory.   To delete
    the  file  drop  to  a  command  window  and  delete it using it's
    shortname (dir /X will display shortnames).  Eric Stevens tried to
    put more light into  this.  The real  issue here seems to  be that
    Windows (all versions  including, but not  limited to Win  95, 98,
    NT4.0 [sp3  & sp4])  apparently only  accept file  names up to 218
    characters in length.   The maximum number  of characters you  can
    enter in the little rename file  box is 214 bytes.  Any  file name
    greater than 218  bytes including extension  and dot is  truncated
    with  out  attention  paid  to  the  extension  in  the truncation
    process.  Example:   aaaa.....aaa.txt of length  219 would  become
    aaaa......aaa.tx .  The Windows standard Save File dialog  (Common
    Dialog  control:   comctl32.ocx)  control  alllows  the  entry  of
    filenames  up  to  apparently  259  bytes,  which will promptly be
    truncated to that 217 byte limit.  This truncation is done by  the
    comctl32.ocx control,  not the  program trying  to save  the file.
    The   program   happily   accepts   the   filename   truncated  by
    comctl32.ocx.  If this program attempts to append an extension  on
    this filename, you may very well have a real issue.  Character 160
    has no bearing on this whatsoever. At 252 characters, applications
    receive errors when trying to save files (tested by an application
    written for this purpose).  Code:

        1     For b = 1 To 300
        2       a = Left(Trim(Str(b + 4)) + String(b, "a"), b) + ".txt"
        3       Open "c:\test\" + a For Output As #1
        4       Close
        5     Next

    Line 2 declares the filename to be the value of b plus 4 (for the
    ".txt" on the end) plus the appropriate number of "a" 's on the
    end.  This piece of code does not truncate the file name in any
    way, just returns a file not found error.  All the files whose
    length are greater than 217 crash on right click or pushing the
    delete button.  The only way apparently to get rid of these guys
    very easily is to just drag them to the recycle bin.

    Let's go back  to original report.   Try sending a  file with  the
    oversied name  attached in  an email  to..   say..   eudora pro or
    something.  Watch what happens  (backup eudora mail before you  do
    it).  And here's the summary of some test.  Also crashes:

        - BeMail (ships with BeOSE)
        - Lotus Notes  (when you try  visualize it.   You can't detach
          the document, but  you can choose  Launch and WordPad  won't
          cash)
        - Pine 3.0 under HP-UX A.09.07 A 9000/712
        - Outlook 98 under Windows NT 4.0 SP?

SOLUTION

    The easiest way to  get rid of one  of these files with  an 'extra
    long' filename, is to drag it  to the recycle bin (that seemed  to
    work fine for me).   This doesn't seem to  affect service pack  4.
    Let's remind of the procmail security filter page at

        http://www.wolfenet.com/~jhardin/procmail-security.html