Apache Vulnerability Announced 307
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.
Enough Already (Score:5, Insightful)
...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".
It's still better than IIS (Score:2, Insightful)
Double standard (Score:2, Insightful)
So your company publicizes a bug for IIS, you're a hero. Publicize one for Apache, you're now "uninformed and questionable"? Geez.
Re:Enough Already (Score:3, Insightful)
Most IIS patches (read: not IE, a completely different product) are out whithin days or a week at the most as well. They're just limited to a very small group of people outside MS that actually have access to it. Many people with certain support agreements can install these "hotfixes" that have not gone through regression testing. The resut of us have to way the 4-8 weeks once MS determines the quality is acceptable for the masses.
Those who run mission critcal web servers generally don't apply the latest patch because it's generally more risky to install a "hot off the compiler" security patch then the security risk itself.
Re:Incoming (Score:4, Insightful)
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.
Re:Double standard (Score:3, Insightful)
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.
Re:Enough Already (Score:5, Insightful)
The reason Microsoft patches are released close to when bugs are announced is because most security researchers withhold their reports until the vendor has a patch ready. Responsible disclosure and all. Eeye discovered the latest
Re:Enough Already (Score:3, Insightful)
Release to a controlled, small subset is essentially the same as not released at all, at least for those unlucky types not in the small, controlled subset.
Re:It's called "Full Disclosure" (Score:2, Insightful)
Like ISS obviously did, one of the first things NGSSoftware did after the
eEye ASP Chunk Transfer Encoding vulnerability came out, was check 'what
else' is vulnerable to this kind of issue. Like ISS, NGSSoftware also noted
that the Win32 distribution of Apache was vulnerable.
However, our approach to addressing this problem was/is completely
different. We alerted Oracle, Apahce and CERT.
Our last response from Mark Fox of Apache was that they "have decided that
we need to co-ordinate this issue with CERT so that we can get other vendors
who ship Apache in their OS and projects aheads-up to this issue."
NGSSoftware, of course agreed that this would be the best plan of action as
most people who use the Win32 Apache version do not have a compiler and so
can take steps to protect themselves. They're mostly relying on their apache
'supplier' to produce a patch.
p.s. the point i was making earlier in this post is that I'm not surprised if MS says they will take forever to put out a patch. I would be highly suprised if the Apache team would have said they were going to take 8 weeks to post their fix and not cooperated with the vulnerability finder. What ISS did was plain irresponsible, especially for a security firm that is publically traded.
Re:Switch to IIS (Score:2, Insightful)
Apache means quality. (Score:5, Insightful)
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.
Re:What happened to disclosure lead times? (Score:3, Insightful)
The fact is, I do trust the Apache group... (Score:5, Insightful)
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
Re:Apache team not trusted (Score:4, Insightful)
To pick a nit, on a number of architectures, the difference is not in the code to compare the quantities but the code in the conditional jump. Somehow casting a signed value to an unsigned value sounds like an opportunity for lots of subtle mischief. The Apache team is wise to examine this stuff carefully and not let themselves get panicked into doing something stupid.
Re:What happened to disclosure lead times? (Score:3, Insightful)
> spoken up are advocates of Security through Obscurity.
> There's no other way of looking at it.
The line is quite thin but it exists.
If (the bug is a simple fix any admin can make):
disclose first
patch later
If (the bug is a grave one ):
If (it is not public knowledge yet and the bug has appeared for only a "short time"):
do NOT disclose
coordinate between vendors
wait for a patch
prepare exploit code
If (it is not public knowledge yet but the bug has appeared "quite some time ago"):
disclose anyway
Patch ASAP, but expect that the bad guys know the vulnerability anyway
It's not perfect, and it depends strongly on reasonable values of "short time" and "quite some time ago", but it's really only fair to the admins. At least they can prepare for the attacks, even if it means kludgistic hole-plugging.
It's at least (more or less, my understanding may well be incorrect) the position of Debian [debian.org]
on security issues.
Anyway, as someone said, admins should remember that unpatched vulnerabilities most likely still exist, and that
good protection includes running Apache as an unprivileged user, possibly in a chrooted environment.
It does not do any good to the web server itself, but it should prevent (hinder) any further contamination.
(yes, I code in Python, how did you know ?)