Apache Vulnerability Announced

Aaron writes "Versions of the Apache HTTP Server up to and including 1.3.24 and 2.0 up to and including 2.0.36 contain a bug in the routines which deal with invalid requests which are encoded using chunked encoding. In some cases it may be possible to cause a child process to terminate and restart, which consumes a non-trivial amount of resources. See the official announcement and stay tuned here for updated versions." This is in response to the rather uninformed and questionable security notice by ISS X-Force, about a bug that has already been mentioned on the public mailing lists for Apache and is fixed in CVS for Apache 2.0. I am also told that their patch doesn't fully solve the problem. I am sure though that by awaking us to the problem they will get a lot of great press just like any of the other companies currently using useless bug announcements as press releases.

Comments

Apache team not trusted

[neoThoth]

I posted this as a story earlier...

Turns out the ISS X-Force team doesn't trust the Apache crew to fix what seems to be a very serious exploitable bug in the http code. They just released an advisory to the Bugtraq mailing list here and provided some 'patch code'. The patch code (which attempted to typcast the vulnerable area) doesn't seem to fix the issue.
So in effect there are a bunch of Apache servers out there with a possibly remote exploitable buffer overflow. Was this a big ooops on the part of ISS?
One has to wonder why they didn't go to the Apache team first with this? Rumor has it that ISS feels that Red Hat has burned them (ISS) in the past and since the Apache team has some Red Hat employees they shouldn't be trusted.
Another rumor that has been floating is that the ISS team doesn't consider Apache to be "a vendor" and therefore doesn't need to follow the normal disclosure rules. This sets a pretty bad precedant of not working with vendors just because you don't get along with them. A companies personal pettiness should not be allowed to override the security of a majority of the internets websites. The patch has offically made it into the Apache CVS but again why the hell didn't ISS talk with Apache? I noticed another post by NGGS (referenced in link above) that they already had a CVS number so they appeared to have gone through the proper channels and got 'beat to the punch' by ISS. Sounds like a motive to me....

Thoughts on this hole

[ajrez]

(A) Bugtraq and associated lists perhaps have held off on posting this, MAYBE, but then this brings us back to the Full Disclosure arguement.

(B) Better question: Why is ISS releasing a poorly researched hole (they didn't even know that Apache 2.x had it) and a worthless patch prior to contacting the vendor? Premature ejaculation here or WHAT?

I fail to see what their hurry was, lest their market share is dipping and they really needed to beat someone (such as David Litchfield?) to the punch.

This is completely irresponsible. There are scores of devices that use Apache embedded. These manufacturers and THEIR clients now need to come up with something *fast* to get locked down.

F'n genius....

ISS patch is not complete

[btellier]

As noted by valcu.gheorghe@caatoosee.ro on Bugtraq:

----
The patch that mentioned casting bufsiz from an int to an unsigned int
failed to do a few things:

1) There are 2 instances of the same code in http_protocol.c that need
to be fixed, as both suffer from the same problem
2) The cast to unsigned int was only done in comparison, and was not
done in assignment, which could possibly lead to problems down the road
with the int value?

I haven't checked any of this, just noticed it and was really just
wondering "why wasn't this done?".

The code that is apparently "buggy" is this:

len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;

The code was mentioned to be changed to this:

len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz :
r->remaining;

However, this doesn't assign that casted value to len_to_read, it just
uses the cast for comparison and then passes on the possibly bogus data
on to len_to_read.

So, should the fix not be to change it to:

len_to_read = (r->remaining > (unsigned int)bufsiz) ? (unsigned
int)bufsiz : r->remaining;

Also, like I mentioned, there are two places where this happens in
http_protocol.c, one at line 2062, and the other (the one mentioned in
the patch) at 2174.

-----

What happened to disclosure lead times?

[Builder]

WTF!?!?!

What happened to the lead time given to a software vendor before publishing a vulnerability ? I thought that all professional 'sploit hunters honoured this.

The idea is to give the vendor time to produce a patch so that when you announce the vulnerability there is an official patch available. It's 22:16 here now and I'll be sat up half the night waiting to see if Apache release a patch because I have around 20 servers that run Apache, and I can't sleep until I know they're secure.

I'm all for full disclosure, but I much prefer RESPONSIBLE full disclosure. If anyone from IIS is reading this, you're a bunch of immature mornons. Play by the rules or fuck off!

Full disclosure and reputations...

[sterno]

Well, I think it can be safely reasoned that ISS cannot be considered a reputable security organization. Do you really want to give these guys any money when:

1) They are unable to fully understand the nature of a discovered flaw

2) They are unable to release a patch that solves the problem (demonstrating a lack of a good QA process)

3) They have demonstrated an inability to work effectively with industry leading software developers

I don't know about you, but I'd be hard pressed to trust my business or even my home data to the security of an organization that is so apparently incompetent. They have a lot of 'splaining to do.

Some more data

[Florian Weimer]

Some more data has become public: Some one close to the Apache team claimed that the IIS patch is wrong, and there's a response from IIS. Maybe the IIS patch does fix the problem, but it is certainly not the most obvious and reader-friendly way to do it.

And, by the way, we have extrated the critical patch from the 1.3.x CVS (currently skipping mod_proxy), created a Debian package containing it, and written a German notice (still preliminary) for our free security newsletter. (The Debian package will be updated as new changes appear in the Apache CVS .)

Re:don't believe the FUD

[Verizon Guy]

You're a fucking idiot. It's not fixed yet.

If anything, this hole just serves (ha!) as a reminder of how superior Apache and open source are in general. Only a fool would use anything else.

I guess that fool is me. Been an IIS user for years. Never r00ted. Not once.

It's called "good system administration."