[ISN] Re: ISS Advisory: Remote Compromise Vulnerability in Apache HTTP Server

From: InfoSec News (isnat_private)
Date: Tue Jun 18 2002 - 03:39:06 PDT

  • Next message: InfoSec News: "[ISN] Secret Service Agent: Hackers Are Unpatriotic"

    Forwarded from: Robert G. Ferrell <rferrellat_private>
    While I generally stay out of the full-disclosure and associated
    topics debate these days because I've already stated my position
    (probably too many times), there are some questions surrounding this
    advisory that I can't help but think ought to be brought out into the
    open. Let me state for the record that I harbor no ill-will toward
    ISS; I just think they might have been a bit out of line here. The
    following discussion is a bit convoluted, so bear with me.
    For any who missed it, here is the advisory itself, as posted on
    Bugtraq.  For the sake of clarity, I'll present my comments at the
    end, rather than mucking up the body of the advisory.
    Internet Security Systems Security Advisory
    June 17, 2002
    Remote Compromise Vulnerability in Apache HTTP Server
    ISS X-Force has discovered a serious vulnerability in the default
    version of Apache HTTP Server. Apache is the most popular Web server
    and is used on over half of all Web servers on the Internet. It may be
    possible for remote attackers to exploit this vulnerability to
    compromise Apache Web servers. Successful exploitation may lead to
    modified Web content, denial of service, or further compromise.
    Affected Versions:
    Apache 1.x
    Note: Many commercial Web Application Servers such as Oracle 9ias and
    IBM Websphere use Apache HTTP Server to process HTTP requests.
    Additional products that bundle Apache HTTP Server for Windows may be
    The Apache HTTP Server is maintained by the Apache Software
    Foundation. Apache is an extremely popular open-source Web server.
    Netcraft (http://www.netcraft.com) reports that as of May 2002, Apache
    accounts for over 63% of all active Web sites. Apache's installed base
    is larger than all other Web servers combined.
    The Apache Project is an open-source and volunteer collaboration aimed
    to create and maintain a free, feature-rich, powerful, and secure Web
    server implementation. Apache is well regarded as the best, freely
    available Web server.
    Apache contains a flawed mechanism meant to calculate the size of
    "chunked" encoding. Chunked encoding is part of the HTTP Protocol
    Specification used for accepting data from Web users. When data is
    sent from the user, the Web server needs to allocate a memory buffer
    of a certain size to hold the submitted data. When the size of the
    data being submitted is unknown, the client or Web browser will
    communicate with the server by creating "chunks" of data of a
    negotiated size.
    The Apache HTTP Server has a software flaw that misinterprets the size
    of incoming data chunks. This error may lead to a signal race, heap
    overflow, and to exploitation of malicious code.
    X-Force has verified that this issue is exploitable on Apache for
    Windows (Win32) version 1.3.24. Apache 1.x for Unix contains the same
    source code, but X-Force believes that successful exploitation on most
    Unix platforms is unlikely.
    Internet Scanner X-Press Update 6.12 includes a check,
    ApacheChunkedEncodingBo, to detect installations of Apache HTTP Server
    for Win32. XPU 6.12 is available from the ISS Download Center at:
    http://www.iss.net/download. For questions about downloading and
    installing this XPU, email supportat_private
    Detection support for this attack will be included in future X-Press
    Updates for RealSecure Network Sensor 6.x and 7.0. These XPUs will be
    available from the ISS Download Center, and this alert will be updated
    when these updates become available.
    ISS X-Force has developed a patch for this issue. Follow the
    instructions below, or contact your vendor for assistance:
    To apply a source code patch to your Apache package:
    1. Locate your source directory and navigate into the "main" sub-
    2. Verify that "http_protocol.c" is present in the current directory.
    3. To update your http_protocol.c file, create a file named
       "apache_patch.diff", containing the following text:
    - --- http_protocol.c.vuln	Fri Jun 14 16:12:50 2002
    +++ http_protocol.c	Fri Jun 14 16:13:47 2002
    @@ -2171,7 +2171,7 @@
          /* Otherwise, we are in the midst of reading a chunk of data */
    - -    len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
    +    len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz : r->
          len_read = ap_bread(r->connection->client, buffer, len_to_read);
          if (len_read <= 0) {
    4. Apply the source code update using the "patch" command, or a similar
    5. Build new binaries and reinstall.
    The Apache Server Project has been notified and will make a formal
    patch available soon. Please refer to the Apache Server Project's
    homepage for more information: http://httpd.apache.org/
    Additional Information:
    This vulnerability was discovered and researched by Neel Mehta of the
    ISS X-Force.
    In order to put my comments into perspective, let's examine the
    (approximate) chronology of events relevant to this announcement:
    1. Mark Litchfield discovers a potential DOS attack while searching for
       Oracle vulnerabilities.
    From the VulnWatch mailing list:
    From: "Mark J Cox" <mjcat_private>
    To: <vulnwatchat_private>
    Sent: Monday, June 17, 2002 11:23 AM
    Subject: [VulnWatch] Apache httpd: vulnerability with chunked encoding
    Date: June 17, 2002
    Product: Apache Web Server
    Versions: Apache 1.3 all versions including 1.3.24, Apache 2 all versions
    up to 2.0.39 
    While testing for Oracle vulnerabilities, Mark Litchfield discovered a
    denial of service attack for Apache on Windows.  Investigation by the
    Apache Software Foundation showed that this issue has a wider scope,
    which on some platforms results in a denial of service vulnerability,
    while on some other platforms presents a potential a remote exploit
    We were also notified today by ISS that they had published the same
    issue which has forced the early release of this advisory.
    The Common Vulnerabilities and Exposures project (cve.mitre.org) has
    assigned the name CAN-2002-0392 to this issue.
    2. As suggested by the above statements, the Litchfields and Apache
    are working together to sort out the problem and take corrective
    3.  ISS releases an unexpected advisory, the one I've included above
    in its entirety. There are two glaring problems with this advisory.
    The first is that they apparently gave Apache no time at all to
    respond before posting on a public forum.  This, most people believe,
    is a no-no.  From what I can see ISS does not contact Apache until
    *after* the advisory is posted, in fact.
    The vulnerability posted by ISS is a little too vague for my tastes,
    but basically it involves a "misinterpretation" of an unsigned int as
    signed.  In order for this to take place, the variable in question has
    to be greater than 32k in value (otherwise it can't be an unsigned
    int).  The "bufsiz" in the advisory is actually (according to the
    Apache source code) assigned to a static variable named
    HUGE_STRING_LEN, which is limited in size in a #DEFINE in httpd.h to
    8192 (8k).  Therefore, it can't be interpreted as unsigned, unless the
    compiler has gone insane.  By my own quick-n-dirty audit, every bit of
    code in the source trees I happen to have that refers to
    HUGE_STRING_LEN contains an include statement for httpd.h. Badda bing,
    badda boom.
    The upshot of this is that the patch supplied by ISS doesn't fix
    anything, at least as far as I can tell.  I'm not an expert coder (or
    expert anything else, with the possible exception of smartass, as I've
    taken pains to point out before), but I've had a true expert whose
    opinion I respect without reservation indicate the same thing to me,
    so I feel fairly secure in this assertion.
    Ok, so we have an advisory, and a patch that doesn't do anything.  
    Not only is the patch of questionable utility, it requires, in their
    (ISS') own words, that the users "build new binaries and reinstall."  
    Now, given the fact that they've stated that Apache for Win32 is
    vulnerable, and remembering that the vast majority of installations of
    Apache on Windows platforms are derived from binary distributions, not
    source code, one has to wonder how these recompilations are going to
    take place.  In point of fact, they're not. At least not at the user
    So, to summarize:
    Mark Litchfield discovered a vulnerability in Apache, and followed
    proper channels by contacting the software maintainer and working with
    them to develop a fix before going public with potentially exploitable
    ISS bypasses accepted channels completely and posts information about
    the vulnerability to a public list, providing at the same time a patch
    that doesn't seem to fix the vulnerability as stated, along with
    installation instructions that, while accurate, are not going to be of
    much use to most Win32 admins.
    Apache is now in the position of having to scramble to release a patch
    before people start exploiting a vulnerability that would not have
    been widely known if ISS had shown a bit more restraint.
    On possible interpretation of the sequence of events (not the only
    one, but the one that strikes me as most likely) is that ISS wanted to
    go on record as having reported the vulnerability in Apache (and these
    are relatively rare) first, come hell or high water.  I understand
    that being first out of the chute can give you a public relations edge
    in the tough, competitive world of information security products and
    services, but it looks to me as though going this route is paramount
    to shooting yourself in both feet with the same bullet.  Being first
    to post a non-existent vulnerability and then providing a patch that
    wouldn't fix it anyway ain't no way to go through life.
    But then, that's just the way I see it.
    Robert G. Ferrell
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.

    This archive was generated by hypermail 2b30 : Tue Jun 18 2002 - 07:41:57 PDT