Security Researchers at N-Stalker’s Web Security Intelligence Labs have unleashed a security flaw that affects all versions of Apache and may cause client-side application to be vulnerable against malicious attackers. According to Thiago Zaninotti, head of the Research Lab, the problem is related to the way Apache handle requests with “Expect” header field set, giving the ability to inject arbitrary HTML code to be rendered in the client-side application.

Before public disclosure, the issue was reported to Apache Foundation in details for software correction. A new release of Apache (1.3.35, 2.0.58, 2.2.2) has been released to cover a range of bugs, including the unfiltered “Expect” header injection. You may find more details at http://httpd.apache.org.

Following below is the official report provided by N-Stalker’s researchers:

During some specific tests with our upcoming Web App Security Scanner tool, we have found that Apache would kindly accept HTML injection through “Expect” header. Originally meant to be a protocol flow control that would give web client the capacity of sending the HTTP headers for server’s pre-analysis before submitting the rest of the payload (body), Expect header is not usually used by common user’s client-side software (for more details see section 8.2.6 from RFC 2616 – http://www.ietf.org/rfc/rfc2616.txt).

During a brief discussion with the gentle guys at security apache org, we had concluded that vulnerability cannot be trivially exploited and its exploitation focus would be client-side software. It was common sense that this flaw should be corrected in latest Apache versions (1.3.35/2.0.58/2.2.2) — which was done, however, it should not be categorized as a security vulnerability.

The software flaw, not being exploitable on common web browser scenario, can be used by malicious software distributors by appending malformed expect headers in outgoing HTTP requests (via common toolbars and web components). The idea would be to render arbitrary HTML code in an obscure way — without leaving traces ( after all, victims would still see connection going to a legitimate web server’s IP address).

Some exploitation can be also considered if an attacker is able to control variables that affect HTTP Header of outgoing requests (i.e: an URI variable that would be used by an asynchronous object to connect back — attacker could use \t tab encoding vulnerability to insert arbitrary headers in the XmlHttpRequest/MSXML request — see Amit Klein’s document at http://seclists.org/lists/webappsec/2005/Jul-Sep/0614.html), however, it is also a rare situation.

The affected source code was (extracted from line 1286 of http_protocol.c of v1.3.34):

    if (((expect = ap_table_get(r->headers_in, "Expect")) != NULL)&& (expect[0] != '\0')) {

    [...] (expect is rendered in the client's browser without further filtering)

    ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_INFO, r,
        "client sent an unrecognized expectation value of "
        "Expect: %s", expect);
        ap_send_error_response(r, 0);

We have prepared a small proof-of-concept test software that is using Microsoft’s ActiveX control WebBrowser to inject malicious Expect eaders. When vulnerable, Apache will display a html message to be rendered back in user’s browser. The idea is to simulate the malicious omponent that would still display correct URL address (right-click under site’s properties), however, rendering a different web page: Download at http://www.nstalker.com/defense/ApacheExpectPOC.zip.

Again, this is a simple and harmless example. For those who are still using old versions of Apache, I recommend upgrading to the latest versions — it does not have a direct impact against your web server, however, you will be protecting client-side against obscure exploitation. See http://httpd.apache.org for more details.

N-Stalker would like to thank Mark Cox and William Rowe for their immediate response and support over this matter. Thanks also goes to OWASP Brazil Chapter’s list for their feedback.