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. """
Created httpd tracking bugs for this issue: Affects: fedora-all [bug 1212431]
This initially came from: http://seclists.org/bugtraq/2015/Apr/90
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.
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.
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.