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.
Proof positive that IIS is a better web server than Apache. You don't see IIS vulnerabilites spouted all over the internet every day.
Cunning linguists
...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?
The Rocjoe Institute is reporting that under some conditions, Windows *may* crash...
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
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....
(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....
I have become, comfortably numb
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.
-----
Consider an application has a vulnerability. After an interval elapses, a patch is released, and peace and order is returned to the world.
If it is an Open Source product, it is lauded as a benefit of the methodology. With "millions of eyes on the code," a problem, once identified, can be resolved. The system works!
If it is Microsoft, the problem is the closed source. If it was open source, either the problem wouldn't be there in the first place, or the fix would come out faster. It is just another show of how it lacks.
This artical, IMHO, is proof that just because it is Open Source does not mean it is bug (or vulernability) free.
As for the time-to-fix, the examples I am used to hearing from the Open Source community is that the patch can be out in a number of hours. I question how much testing went on in the fix in terms of bredth of hardware and software integration, etc. The impression I left with is someone went out and whipped up something that appears to fix the problem. The initial fix plugs the hole, then others come behind them and make it better integrated (i.e. fewer bugs, etc.).
What is the problem with this? None, I suppose. However, I fail to understand how this is really better, other than the fact that some "beta" code was released "in hours". Certainly not so much better than it merits all the looking-down-the-nose at other platforms.
I also have a pet theory, which I often state. One of the reasons all crackers et al. go after Microsoft product is that they are widely used, and that showing their failings through breaking them gains them esteme on boards such as this one. Typcially, someone breaking in to an IIS site is condemed, but rather the SysAdmins for using IIS (regardless of application, corporate, or other requirements). This comes accross as condoning this behavior, and causes more people to do more damange.
No, I don't think that doing otherwise will minimize the number of vulnerabilities or attacks, nor do I feel vulnerabilities shouldn't be fixed.
> PHP doesn't work on 2.0 yet, so upgrading to 2.0 is not an option for us. Now what?
Meanwhile, if you HAVE to use Apache 2.0, run PHP as CGI and you will avoid the version hassle (ofcourse loosing on performance etc). Anyway, it won't take long now to have PHP4 working good as module with 2.x, as the big guys are saying that the Apache API is now kind of stabile for 2.x series.
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!
In this case, HELL YES!
The patch they provide doesn't solve the problem, they failed to give the vendor any notice and they didn't even work out exactly what is affected. That sounds a lot like uninformed and questionable to me.
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.
This sig has been temporarily disconnected or is no longer in service
Please note that the patch provided by ISS does not correct this vulnerability.
Will upgrading to 32-bit color on my hard drive fix it or do I need to upgrade my monitor refresh rate to 512MB?
Someone you trust is one of us.
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
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.
from Bugtraq a few minutes ago:
---
ISS has requested that I forward this response to the list.
----------
This vulnerability was originally detected auditing the Apache 2.0 source
tree. Apache 2.0 uses the same function to determine the chunk size, and
has the same vulnerable signed comparison. It is, however, not vulnerable
(by luck?) due to a signed comparison deep within the buffered reading
routines (within core_input_filter).
This issue is no more exploitable or unexploitable on a 32-bit platform than
on a 64-bit platform. Due to the signed comparison, the minimum size passed
to the memcpy() function is 0x80000000 or about 2gb. Unless Apache has over
2gb of contiguous stack memory located after the target buffer in memory, a
segmentation fault will be caused. If you understand how the stack is used,
you will understand that this is an impossibility.
Apache on "Win32" is not exploitable due to any "64-bit" addressing issues.
It is easily exploitable due to the nature of structured exception handling
on Windows and the fact that exception handler pointers are stored on the
stack.
If the DoS vulnerability is related to the overflow then the ISS patch will
work to prevent it. The unsigned comparison prevents any stack overflow and
as a result any related DoS issue is prevented. If the DoS issue is
unrelated, then of course the ISS patch will not be of any help.
ISS X-Force
----
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
Versions of the Apache web 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. This bug can be triggered remotely by sending a carefully crafted invalid request. This functionality is enabled by default.
In most cases the outcome of the invalid request is that the child process dealing with the request will terminate. At the least, this could help a remote attacker launch a denial of service attack as the parent process will eventually have to replace the terminated child process and starting new children uses non-trivial amounts of resources.
We were also notified today by ISS that they had published the same issue which has forced the early release of this advisory. Please note that the patch provided by ISS does not correct this vulnerability.
The Apache Software Foundation are currently working on new releases that fix this issue; please stay tuned here at http://httpd.apache.org/ for updated versions as they become available.
[Link to full advisory follows at http://httpd.apache.org/info/security_bulletin_200 20617.txt ]
For mirrors: http://www.apache.org/dyn/closer.cgi/httpd/
For direct download: http://www.apache.org/dist/httpd/
For the announcement: http://httpd.apache.org/