******************************************************************************
             ------               -----   -----  ---     -----
             |      ----- ----   |          |    |  |   |
             |---   |     |   |  |          |    |  |   |
             |      |--   |   |  |          |    |--    |
             |      |     |   |  |          |    | \    |
             |      ----- ----    -----   -----  |  \    -----

                               A D V I S O R Y

           FA-98.11
******************************************************************************
Topic: Microsoft Windows-based Web Servers unauthorized access - long file
       names
Source: CERT/CC

Creation Date: February 06, 1998
Last Updated: February 11, 1998
        Advisory name change
        Updates to Solution Section III.B
        Added Acknowledgment
        A complete revision history is at the end of this file.

To aid in the wide distribution of essential security information, FedCIRC is
forwarding the following information from CERT/CC Advisory CA-98.04. 
FedCIRC urges you to act on this information as soon as possible.

If you have any questions, please contact FedCIRC:

        Telephone:      +1 888 282 0870
        Email:          fedcirc@fedcirc.gov



=======================FORWARDED TEXT STARTS HERE============================

-----BEGIN PGP SIGNED MESSAGE-----

=============================================================================
CERT* Advisory CA-98.04
Original issue date: Feb. 06, 1998
Last revised: February 11, 1998
        Advisory name change
        Updates to Solution Section III.B
        Added Acknowledgment

        A complete revision history is at the end of this file.

Topic: Microsoft Windows-based Web Servers unauthorized access - long file
       names
- -----------------------------------------------------------------------------

An exploitation involving long file names on Microsoft Windows-based web
servers has recently been described on public mailing lists. When files on the
web server have names longer than 8.3 (8 characters plus a 3-character
extension), users can gain unauthorized access to files protected solely
by the web server.

The CERT/CC team recommends installing patches from your vendor (see Section
III.A and the appendix). Until you are able to do so, we urge you to use the
workaround described in Section III.B.

We will update this advisory as we receive additional information.
Please check our advisory files regularly for updates that relate to your site.

- -----------------------------------------------------------------------------

I.   Description

     All 32-bit Microsoft Windows operating systems (commonly known as Win32)
     can associate two different file names with a stored file, a short name
     and a long name. The short version, known as 8.3-compliant, is restricted
     to a length of 8 characters and an extension of 3 characters. This
     version is required for backward compatibility with DOS. The long version
     of the file name is not restricted to the 8.3-compliant format but is
     restricted to a total length of 255 characters.

     When Win32 stores a file with a short name (i.e., 8.3-compliant), it
     associates only that short file name with the file. However, when Win32
     stores a file with a long name (i.e., greater than 8 characters), it
     associates two versions of the file name with the file--the original, long
     file name and an 8.3-compliant short file name that is derived from
     the long name in a predictable manner.

     Example:

       The 8.3-compliant short file name "Abcdefgh.xyz" is represented
                      (1) as is: "Abcdefgh.xyz".

       However, the long file name "Abcdefghijk.xyz" is represented:
                      (1) as is: "Abcdefghijk.xyz" and
                      (2) as 8.3-compliant: "Abcdef~1.xyz".

       Some Win32-based web servers have not compensated for the two file name
       versions when restricting access to files that have long names. The web
       servers attempt to restrict access by building an internal list of
       restricted file names. However, for files with long names, only the
       long, and not the short, file name is added to this internal list. This
       leaves the file unprotected by the web server because the file is still
       accessible via the short file name.

       For example, "Abcdefgh.xyz" (short) would be protected by the web
       server, but "Abcdefghijk.xyz" (long) would not be completely protected
       by the web server.

II.  Impact

     Users are able to gain unauthorized access to files protected solely by
     the web server.

III. Solution

     CERT/CC urges you to immediately apply vendor patches if they are
     available. Until you are able to do so, we urge you to use
     the workaround described in Section B.

     A. Obtain and install a patch for this problem.

        Appendix A contains input from vendors who have provided information
        for this advisory. We will update the appendix as we receive more
        information. If you do not see your vendor's name, the CERT/CC
        did not hear from that vendor. Please contact your vendor directly.

     B. Until you are able to install the appropriate patch, we recommend the
        following workaround.

        (1) Use only 8.3-compliant short file names for the files that
            you want to have protected solely by the web server. On FAT
            file systems (16-bit) this can be enforced by enabling (setting
            to 1) the "Win31FileSystem" registry key (registry path:
            HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\).

        (2) On NTFS (32-bit), you can disable the creation of the
            8.3-compliant short file name for files with long file names
            by enabling (setting to 1) the "NtfsDisable8dot3NameCreation"
            registry key (registry path: HKEY_LOCAL_MACHINE\System\
            CurrentControlSet\Control\FileSystem\). However, this step may
            cause compatibility problems with 16-bit applications.

        (3) Use NTFS-based ACLs (directory or file level access control
            lists) to augment or replace web server-based security.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Appendix A - Vendor Information

Below is a list of the vendors who have provided information for this
advisory. We will update this appendix as we receive additional information.
If you do not see your vendor's name, the CERT/CC did not hear from that
vendor. Please contact the vendor directly.

Apache
======
None of the beta releases of Apache for Win32 are vulnerable to this
particular problem.


Microsoft
=========
Microsoft IIS 4.0 and PWS 4.0 with the appropriate patch are not
vulnerable.

IIS 4.0 and PWS 4.0 maintain certain configuration information about
directories and files in a database called the metabase. The metabase does
not contain file permissions, but rather Web server-specific information
such as requiring SSL encryption, proxy cache setting, and PICS ratings.
Actual file and directory permissions are enforced by NTFS and are not
affected by this problem.

Earlier version of IIS and PWS are not vulnerable to this issue.

Microsoft has made available a market bulletin for this issue that is
available on "Advisories and Solutions" section of the Microsoft Security
Advisor web site, http://www.microsoft.com/security. Please consult this
bulletin for information on obtaining the patch.


National Center for Supercomputing Applications (NCSA)
======================================================
The NCSA HTTPd web server does not run on Windows NT.  Note that HTTPd
is now an unsupported software product of the National Center for
Supercomputing Applications.

- -----------------------------------------------------------------------------
The CERT Coordination Center thanks David LeBlanc for his workaround suggestion.
- -----------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/).


CERT/CC Contact Information
- ----------------------------
Email    cert@cert.org

Phone    +1 412-268-7090 (24-hour hotline)
                CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
                and are on call for emergencies during other hours.

Fax      +1 412-268-6989

Postal address
         CERT Coordination Center
         Software Engineering Institute
         Carnegie Mellon University
         Pittsburgh PA 15213-3890
         USA

Using encryption
   We strongly urge you to encrypt sensitive information sent by email. We can
   support a shared DES key or PGP. Contact the CERT/CC for more information.
   Location of CERT PGP key
         ftp://ftp.cert.org/pub/CERT_PGP.key

Getting security information
   CERT publications and other security information are available from
        http://www.cert.org/
        ftp://ftp.cert.org/pub/

   CERT advisories and bulletins are also posted on the USENET newsgroup
        comp.security.announce

   To be added to our mailing list for advisories and bulletins, send
   email to
        cert-advisory-request@cert.org
   In the subject line, type
        SUBSCRIBE  your-email-address

- ---------------------------------------------------------------------------

Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to cert@cert.org with
"copyright" in the subject line.

*CERT is registered in the U.S. Patent and Trademark Office.

- ---------------------------------------------------------------------------

This file: ftp://ftp.cert.org/pub/cert_advisories/CA-98.04.Win32.WebServers
           http://www.cert.org/pub/alerts.html



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history

Feb. 11, 1998  Advisory name change
               Updates to Solution Section III.B
               Added Acknowledgment

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNOHMeHVP+x0t4w7BAQEE0QP/Ym6fI4HPsSJs6hMuZJVM+Gi7yO5uhuDL
X4ZrwlPizkyqIysb4oaWMJpsmbCYHD6tTYIOYwfDSJfwI0tUGXsIRy3BYA8lRoMj
kNqFJFaLUqmKxy+vsxBv9dG5OFE3xzolm/QMR5YppQLpqYil6aIFW3LeRWRJs/E9
0fbKCqaJIyw=
=k7GD
-----END PGP SIGNATURE-----


========================FORWARDED TEXT ENDS HERE=============================

The National Institute of Standards and Technology (NIST) has
established a Federal Computer Incident response Capability (FedCIRC)
to assist federal civilians agencies in their incident handling
efforts by providing proactive and reactive computer security related
services.  FedCIRC is a partnership among NIST, the Computer Incident
Advisory Capability (CIAC), and the CERT* Coordination Center
(CERT/CC). 

If you believe that your system has been compromised, please contact
FedCIRC: 

        Telephone:      +1 888 282 0870
        Email:          fedcirc@fedcirc.gov
        Web Server:     http://www.fedcirc.gov/

* Registered in U.S. Patent and Trademark Office
 
The CERT Coordination Center is part of the Software Engineering
Institute.  The Software Engineering Institute is sponsored by the
U.S. Department of Defense.

CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.
 
This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.