httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Tagging 2.2.15 to play openssl catchup?
Date Sun, 28 Feb 2010 18:42:51 GMT
On 2/25/2010 3:36 PM, William A. Rowe Jr. wrote:
> I'd like to move ahead and catch up to OpenSSL 0.9.8m which was released today,
> and that requires a 2.2 release.
> Let's start a three day clock to the tag, and I'll tag Sunday about noon CST.
> That gives folks friday, and weekend warriors time Saturday to catch up with
> final important bugfix backports, and testers can pick this up Sunday afternoon
> or anytime Monday/Tuesday.

There is a remaining showstopper, an invalid veto by niq that is missing votes,
probably due to the "you two figure it out, and then we'll decide" syndrome, but
it appears that is not going to happen so we need the technical input of the dev
community, particularly module authors;

  * Ensure each subrequest has a shallow copy of headers_in so that the
    parent request headers are not corrupted.  Eliminates a problematic
    optimization in the case of no request body.  PR 48359
    [Jake Scott, William Rowe, Ruediger Pluem]
    Link to discussion thread;
    Applied to trunk;
    Ported to 2.2 (also attached to PR);
    +1: wrowe
    -1: niq: this risks breaking existing apps, as discussed in
             comments on PR 48359.
             [wrowe notes; incorrect and invalid objection, also as
              identified in the comments.  Legitimate API users are
              presently broken by this memory scope flaw.]

In short, niq contends that the implementation is the API.

And in short, I contend that the API defines that manipulation of a subrequest rec must
not intentionally poison the parent request rec, even a student of module authoring
such as Jake recognized this very quickly.  The API defines that walking r->main is
the method to access a parent request's fields for deliberate modification.

So in summary, niq contends there would be deliberate users of the present API who
are handling allocations correctly.

And in summary, I contend that mod_headers is a symptom that users are not aware
what they have manipulated request data out-of-scope, and that there more users
affected by this bug than there are users who deliberatly used it as-is.

To determine whether the user can reasonably expect to deliberately alter the parent
headers_in array we look to the code.  As things stand, if the parent request has a
message body, that answer is no; the private copy is modified, today.  The module
cannot reasonably modify headers_in without walking r->main to determine if headers_in
has changed, or if the parent has a request body.

And finally, this is a showstopper; as I suggest this is one symptom of a larger
problem.  As I brought up on security@, I recived a report of response pollution
from one request to another request, based on passing the current arbitrary string
from an entirely different client address is now sitting in memory at the address
of the former subrequests' allocation.  As this will become a security release,
this clearly needs to be fixed somehow.  Cross request pollution gives worker and
event mpm's bad names.

Nick, you have refused to comment on this since your vote, while I've gone to
great effort to further explain why your argument is broken.  Since you have not
defended the technical merits of your veto in light of these facts, we must tally
your silence as resignation that your initial concerns were misplaced.  I am pulling
your vote with your incorrect observation and our commentary, and invite you to
vote again in the affirmative, or negative with a revised rational.


Please review the simple, attached patch for inclusion in 2.2.15, which aligns
the behavior of subrequest input headers of a bodyless parent request to the
behavior when the parent request contains a message body.

View raw message