Am 29.09.2014 um 09:56 schrieb Issac Goldstand:
On 29/09/2014 00:00, Rainer Jung wrote:
Am 28.09.2014 um 09:07 schrieb Issac Goldstand:
-0
While I love the code that's been come up with, this would be akin to
trying to have patched httpd to deal with Heartbleed.
I can't see any real use-case where a user would get a patched httpd
without getting a patched bash, too. Either they'll know, or they'll be
getting this from their distro's package manager (and we know how long
that'll take to propagate anyway).
Those patches were never meant to be incorporated in an httpd release.
OK - just wanted to clarify that, then :)
They can be useful though because they are a short term temporary
workaround for people who can - for whatever reason - not quickly update
their bash and at least want to close the CGI problem. Of course the
bash update is the way to go, but as we all have learned in the meantime
closing all gaps in bash is a non-trivial exercise. Filtering our
incoming data before forwarding was much easier an AFAIK is is still a
valid temporary solution to the CGI attack vector.
Oh, I absolutely agree with that sentiment. But that's with hats other
than httpd committers (which I personally don't think is the same as,
for example, your infra hat).
Agreed. Discussing workaround patches here (committer head) nevertheless
has the benefit of providing users with options even if not contained in
releases.
Real use case? As an example I deployed the two patches for HTTP header
filtering and CGI env var creation on our two most important ASF web
servers instantly after I wrote them and that was earlier than the
availability of the first official OS patches for bash.
Getting a bit off-topic here, but do we have any idea of the effect that
this had? Did the ASF have any way of noticing "Suspicious" traffic of
the sort either before or after the patch?
Not that I'm aware of and I did not add logging to the value sanitizing.
Regards,
Rainer
