COMMAND

    kernel (Win32 File Naming)

SYSTEMS AFFECTED

    Win 9x, NT with long filename support

PROBLEM

    x-empt  [  lvhc  /  lou  ]  found  following.   While  testing IIS
    security, he was able to locate an old flaw which is still present
    in many  server services  on   Win32.   The problem  deals with  a
    compatibility  issue  with  the  old  Win16/DOS file naming system
    known as the 8.3 naming system.  Files using the 8.3 naming system
    consist of 8 characters followed by a period (.) and a 3 character
    extension, thus giving a name of "8.3".  Many product in use today
    are still affected heavily by this ancient limit.

    IIS
    ===
    Even though IIS is "fixed" the problem has "naturally" occurred on
    one  of  my  servers  even  after  SP5  was  installed.  Microsoft
    Internet Information Server 4.0 allows privileges to be  inherited
    from  parent  directories  instead  of  requested directory if the
    requested directory is a long file name. Example:

        C:\inetpub\wwwroot\ (directory listing enabled)
        C:\inetpub\wwwroot\subdirectory\ (listing _disabled_)
        REQUEST http://server/subdirectory/
          (denied error msg)
        REQUEST http://server/subdir~1/
          (listing of directory)

    IIS / PWS  -- Although this  is not a  major security problem  for
    most, remote  systems security  is compromised  as scripts  can be
    executed.  File listings displayed (although security never  truly
    existed on the  "security through obscurity"  model... *hint*hint*
    Microsoft....)

    N.B.: Service Pack 4/5 seems to fix this, but we had had it  occur
          after  installing  other  software,  so after installing any
          package make sure you re-apply a service pack.

    IIS Privileges  are inherited  from parent  directories.   Virtual
    Directories are not affected as they are VIRTUAL!

    How to reproduce (do not perform this live on the Internet...):

        1) mkdir C:\inetpub\wwwroot\subdirectory\
        2) mkdir C:\inetpub\wwwroot\subdirectory\subdirectory2\
        3) set "C:\inetpub\wwwroot\subdirectory\" privileges to listing
        4) set "C:\inetpub\wwwroot\" privileges to no listing
        5) request "http://localhost/subdir~1/" (you will see a listing for "subdirectory2")

    SERV-U FTP (www.cat-soft.com / www.ftpserv-u.com)
    =================================================
    Certain commands  in Serv-U  are not  properly validated  with the
    access control list.  Rob Beckers has been notified of the  issue.
    Serv-U 2.5a has two known improperly checked commands.  "cwd"  and
    "site  exec"  both  do  not  check  the specified path against the
    access lists properly.  How to reproduce:

        1) mkdir C:\tmphome
        2) mkdir C:\tmphome\longsubdir\
        3) set permissions for "C:\tmphome\" for execute
        4) set permissions for "C:\tmphome\longsubdir\" _NO_ execute
        5) place an exe in "C:\tmphome\longsubdir\"
        6) Login to serv-u
        7) run command "site exec C:\tmphome\longsu~1\exename.exe"
        8) Its running.

    VQSERVER (http://www.vqsoft.com/)
    =================================
    Steve Shering  has been  notified in  advance of  this release via
    email.  This issue is very similar to the IIS issue.  This exploit
    is so  similar to  the IIS  problem, you  can go  figure it out by
    yourself.

    XITAMI web server
    =================
    Tested on: Xitami v2.4d2

SOLUTION

    One well-known workaround  for this issue  that will take  care of
    this problem,  regardless of  the server  software, is  to disable
    8.3 filenames.  If you open the following registry key:

        HKEY_LOCAL_MACHINE\System
	        \CurrentControlSet
		        \Control
			        \FileSystem

    And  create  a  value  named  NtfsDisable8dot3NameCreation,   type
    REG_DWORD, and  set it  to 1,  then the  operating system will not
    create 8.3 filenames.  Note that this isn't retroactive, so  you'd
    need to move any trees you want updated, and then move them  back.
    This  is  something  that  should  be  on  anyone's checklist when
    setting up a web  or FTP server prior  to putting content on  that
    server.   BTW,  setting  this   value  also  gets  you  a   modest
    improvement in file system performance.  It will also break 16-bit
    apps, but hopefully you're not running any antique applications on
    your  server.   As  always,  test  this  sort of change thoroughly
    before putting it into production.   Oh - and obviously this  only
    works if you're using NTFS.