Bug 1212429

Summary: httpd: NULL pointer dereference in server/protocol.c
Product: [Other] Security Response Reporter: Vasyl Kaigorodov <vkaigoro>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED INSUFFICIENT_DATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: cdewolf, ceph-eng-bugs, dandread, darran.lofthouse, dknox, jason.greene, jawilson, jclere, jdoyle, jkaluza, jorton, kkhan, lgao, mmaslano, myarboro, pahan, pgier, pslavice, rmeggins, rsvoboda, twalsh, vtunka, webstack-team, weli
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-23 13:41:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1212431    
Bug Blocks: 1212430    

Description Vasyl Kaigorodov 2015-04-16 11:55:28 UTC
Below issue was reported in Apache httpd:

"""
  Affected code
 ===============
 * protocol.c --- routines which directly communicate with the client.
 *
 * Code originally by Rob McCool; much redone by Robert S. Thau
 * and the Apache Software Foundation.


 PoC 1 - Code Snippet [CWE-476]
 ==============================
 (..\httpd-2.2.29\server\protocol.c:1286)
 (..\httpd-2.4.12\server\protocol.c:1286)

...

AP_CORE_DECLARE_NONSTD(apr_status_t) ap_content_length_filter(
    ap_filter_t *f,
    apr_bucket_brigade *b)
{
    request_rec *r = f->r;
    struct content_length_ctx *ctx;
    apr_bucket *e;
    int eos = 0;
    apr_read_type_e eblock = APR_NONBLOCK_READ;

    ctx = f->ctx;
    if (!ctx) {
        f->ctx = ctx = apr_palloc(r->pool, sizeof(*ctx));
        ctx->data_sent = 0;
    }

Description: Code at line 1286 is vulnerable to a Null Pointer
Derference security issue,  where (request_rec *r = f->r;).  The
filter is used to compute the Content-Length, but it also computes the
number of bytes sent to the client.
....................................................................
The filter will always run through all of the buckets in all brigades.
The (request_rec *r = f->r;) is user-controllable and can be set to
NULL using a supplied parameter. The issue stems from the lack of any
control metrics on the return value of (f) ~ line 1286 (to ensure that
is non-NULL.)

The value of (f) can be set to NULL using a user-supplied parameter.
"""

Comment 1 Vasyl Kaigorodov 2015-04-16 11:57:10 UTC
Created httpd tracking bugs for this issue:

Affects: fedora-all [bug 1212431]

Comment 2 Vasyl Kaigorodov 2015-04-16 12:15:09 UTC
This initially came from:  http://seclists.org/bugtraq/2015/Apr/90

Comment 3 Joe Orton 2015-04-23 11:52:50 UTC
When the content-length filter is added, f->r is non-NULL:

        ap_add_output_filter_handle(ap_content_length_filter_handle,
                                    NULL, r, r->connection);

there is only one time this happens in httpd.

Use of this filter with f->r set to NULL would be a bug, but the burden of proof is on the reporter to show such that a bug exists, not merely that such a bug could exist.  There is no security issue here.

Comment 4 Joe Orton 2015-04-23 12:02:20 UTC
Re-reading, the complaint may be only that f can be NULL, rather than f->r, but the point is the same, the burden of proof has not been met to show that such a bug exists.

Comment 5 Tomas Hoger 2015-04-23 13:41:52 UTC
My reading of the report is that there is NULL pointer dereference when ap_content_length_filter() is called with f == NULL.  However, there's no indication there's any code path that lead to such call, and that it can be triggered remotely.