Slashdot Mirror
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.
...oh, wait.
You mean *nix admins actually have to worry about patches and service packs too?
Don't get me wrong, I don't intend this to be an "I told you so!" from the MS camp to the *nix camp, but rather a polite reminder that all admins have to keep up with their patches, service packs, and whatever. You can't just install Apache and let it go. You need to know what you're doing.
There's a difference between an "admin" and "someone who installed some software".
Got Rhinos?
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....
From the bulletin:
Due to the nature of the overflow on 32-bit Unix platforms this will cause a segmentation violation and the child will terminate. However on 64-bit platforms the overflow can be controlled and so for platforms that store return addresses on the stack it is likely that it is further exploitable. This could allow arbitrary code to be run on the server as the user the Apache children are set to run as.
It seems that thanks to the *nix way of handling processes and their childs, this represents minor threat than on other platforms, in which it is even more easily exploitable as a DOS attack. However, this is not minor news eve for us using *nix breeds.
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.
-----
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!
I have to say, the Apache web server is quite a high quality piece of work. The fact that an obscure security issue has been found is a good sign that developers and users are on top of things in the constant struggle against remote exploiters.
I am confident that a fix will be available very shortly. Serious sysadmins will have their servers patched sooner than any serious damage takes place. I don't have the same confidence when it comes to Microsoft's products.
The fact is, I do trust the Apache group. And for good reason. I know the code is flawed because I write software for a living. All code is flawed, and to believe otherwise is folly. I also know that the competing products are also flawed. What Apache offers that none of their major competitors provide is access to the code. Give me the patch, and I'll apply it myself. If I'm still concerned, I can have a look around the code. And most importantly, they do a much better job at getting the fixes out in a timely manner.
Unfortunately, the exploit clock is now actively running which, no thanks to ISS, was an otherwise unnecessary hassle. That said however, I am confident that hundreds of very concerned and capable open source programmers will be able to outpace the dozen or so overworked and underpaid software engineers who have the misfortune of handling Microsoft's IIS holes.
Lastly, the vendors who provide Apache in their distributions do not have a monopoly on the market place. Their response time is critical to their relationship with their customers. Microsoft, by comparison, has no such relationship with their customers. Having personally been on the receiving end of many thousands of hours of Microsoft's service contracts, partnership deals, inside promotions, and developer support, I can safely say that we spent a lot of money for nothing. Microsoft ignores their preferred partners and Fortune 500 customers just as much as they discount the average desktop user. Through various positions, I've participated directly in all three cases, and after years of poor support from Microsoft, Linux has become a necessary and major factor in how I do business.
-Hope