Apache/Tomcat Denial Of Service And Information Leakage Vulnerability

From: alias@securityfocus.com
Date: 12/04/02

  • Next message: Martin Schulze: "[SECURITY] [DSA 204-1] New kdlibs packages fix arbitrary program execution"
    Date: 4 Dec 2002 22:42:21 -0000
    From: alias@securityfocus.com
    To: undisclosed-recipients: ;

                Qualys Security Advisory QSA-2002-12-04
                            December 4th, 2002
    Apache/Tomcat Denial Of Service And Information Leakage Vulnerability
    - mod_jk 1.2 using Apache Jserv Protocol 1.3
    - Apache 1.3.x 
    - Tomcat 4.x Server
    The Apache HTTP Server Project is an effort to develop and maintain an 
    open-source HTTP server for operating systems including UNIX and 
    Windows NT. Apache has been the most popular web server on the Internet 
    for the last 5 years.
    The Jakarta Project (http://jakarta.apache.org) creates and maintains 
    open source solutions on the Java platform for distribution to the 
    public at no charge. Tomcat 4 is the official Reference Implementation 
    of the Servlet 2.3 and JavaServer Pages 1.2 technologies.
    Mod_jk is an apache module which allows apache to deliver web requests 
    transparently to the tomcat engine. It supports serveral protocols, in 
    particular the Apache Jserv Protocol 1.3 (AJP13).
    When these components are combined there exists an inconsistency in the 
    communcation protocols implemented by mod_jk which allows amalicious 
    user to desynchronise Apache-Tomcat communications and render the 
    Tomcat service useless until the operator can intervene. The nature of 
    the desynchronisation may also result in information leakage which may 
    be used to collect private data from legitimate users of the site.
    A client may connect to the target machine and deliver several requests 
    with an invalid chunked encoded body e.g.
    GET /index.jsp HTTP/1.1
    Host: victim.com
    Transfer-Encoding: Chunked
    The request path is not relevant, after several requests like this are 
    made the server becomes desynchronised and other users of the site will 
    begin to see responses mixed between users. The site responses get 
    desynchronised with the requests and the server becomes useless until 
    either apache or tomcat are restarted.
    The reason this happens is that mod_jk misinterprets the chunked 
    request,  after sending the request to Tomcat via AJP13 it immediately 
    sends a second zero length AJP13 packet (4 bytes - magic number + zero 
    size). The tomcat server receives the first request and sends the 
    response back over the connection. Upon receiving the second zero size 
    packet it repeats the query, and again sends a second response back to 
    Mod_jk is only expecting one valid response, so it pulls it off the 
    wire and leaves the second response untouched. The next request which 
    is sent over this connection (valid or invalid) will generate another 
    response,  however mod_jk pulls the old duplicate response off the wire 
    and sends this back to the requesting agent. Essentially this 
    desynchronises the queries and responses leaving the communication 
    channel useless, furthermore, repeated requests will eventually fill up 
    the network buffers resulting in the requests blocking and the server 
    completely failing to respond.
    Mod_jk uses a pool of workers so a full scale denial of service would 
    require desyncrhonising all of the workers using multiple requests. The
    Number of requests required to block a worker completely will depend on 
    the size of the response and the network buffers.
    The potential for information leakage is great but the risk is 
    mitigated somewhat by the unpredictability of the query-response 
    desynchronisation. Depending on the target site this may be somewhat 
    exploitable by a malicious user to redirect  other users to a specific 
    response by saturating the communcation channels with a desired response.
    Upgrade to mod_jk 1.2.1
    The issue was analysed and documented by the Qualys Security Research 
    Team based on a discovery by Grand Central Communications 
    (www.grandcentral.com) while using the QualysGuard vulnerability 
    detection Service.
    For more information about the Qualys Security Research Team, visit 
    our website at http://www.qualys.com or send email to 
    The information contained within this advisory is Copyright (C) 2002
    Qualys Inc.  It may be redistributed provided that no fee is charged 
    for distribution and that the advisory is not modified in any way.