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

Switch to IIS

[l33t j03]

Proof positive that IIS is a better web server than Apache. You don't see IIS vulnerabilites spouted all over the internet every day.

Re:Switch to IIS

[krogoth]

"You don't see IIS vulnerabilites spouted all over the internet every day."

Yes, they tried but it's hard to get people to work on weekends.

Re:Switch to IIS

[*xpenguin*]

We need a (-1, Dumbass) moderation.

Re:Switch to IIS

[rseuhs]

Actually, this isn't funny - it's sad. Because those small glitches in open-source software that are hyped up to mega-bugs like this one are not even newsworthy when happening in IIS. I have yet to see a news article about a IIS-bug that did not allow to take over the whole machine, but I see trivial ("if you run that platform and if that may happen and if that is enabled than it might lead to a DOS attack") about OSS all the time.

I still remember the so-called ssh vulnerability about keystroke-intervals, which allowed an attacker to reduce the brute-force attack - time from 10 gazillion years to 2 gazillion years. (This so-called vulnerability was so irrelevant it's no longer funny. Why such crap gets accepted on slashdot - I don't understand that.)

Even slashdot has this tendency as it reports every tiny OSS-bug, but only reports the really huge-MS holes where you could drive a truck through.

Microsoft enjoys a great PR-advantage, even on slashdot.

Enough Already

[zpengo]

Boy, it's a good thing these problems only affect Micro$oft server software, because it sure would be a pain in the neck if...

...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".

Re:Enough Already

[Fantanicity]

I don't intend this to be an "I told you so!"

Good ... because IIS had a more serious problem with chunking

Re:Enough Already

[Telastyn]

Actually it's not even an MS vs *nix debate, as Apache runs perfectly well on Win32 thank you. And there's also a big difference between a vulnerability which causes "non-trivial resource usage" and a vulnerability which owns your box. Not to mention that given the nature of the bug, the effects are likely much worse on apache running on win32 than on *nix.

Re:Enough Already

[tshak]

Now for the "But Apache will be patched in 1/5th the time it takes MS to patch IIS" replies.

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:Enough Already

[SirSlud]

1. What about this story has anything to do with *nix admins forgetting to install patches, and/or assuming their software is bugproof?

2. This bug affects Windows too (exploitably, apparently, while the bug is only DoS under 32 bit unix systems)

3. Who ever said *nix software never had problems/bugs? Maybe, arguably, less, but nobody contends that anything is perfect or ever will be, unless we can include marketing departments.

4. We know there is a difference between "admin" and "someone who installed some software". Everybody knows that.

Re:Enough Already

[krogoth]

You are possibly correct - on 64-bit Unix and Windows platforms it can give remote access. Note that you need a 64-bit platform to go beyond a DoS on Unix.

Re:Enough Already

[krogoth]

All software is likely to have bugs, but some are more serious than others. Look at the Apache advisories so far this year - I think attackers can read directories in the web root when auto-indexing is off (another reason not to rely on security through obscurity)! Now compare this to the average IIS vulnerability (which are also more frequent).

Re:Enough Already

[homer_ca]

"Most IIS patches (read: not IE, a completely different product) are out whithin days or a week at the most as well."

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 .htr bug in IIS and they waited until the hotfix was ready.

Re:Enough Already

[gilroy]

Blockquoth the poster:

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.

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:Enough Already

[SealBeater]

It's pretty funny that you say that. From the email


X-Force has verified that this issue is exploitable on Apache for
Windows (Win32) version 1.3.24. Apache 1.x for Unix contains the same
source code, but X-Force believes that successful exploitation on most
Unix platforms is unlikely.


and

From Apache.org:
In Apache 1.3 the issue causes a stack overflow. 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.

We have been made aware that Apache 1.3 on Windows is exploitable in this
way.


Now, what were you saying about Windows vs. *nix?

SealBeater

Re:Enough Already

[_Sprocket_]

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.

Enough already, indeed. One of the very basics to system administration is system maintenance. The uninformed my think IT infrastructures work as "fire and forget" systems. But I have yet to see any such claim stated in this forum or included on any story submission. Yet it has become a popular point for any pro-Microsoft security argument.

You're stating the obvious. And missing the point.

If one wanted to view security vulnerabilities / announcements as more than good information to know, one has to look deeper at the issue. What is the vulnerability? What level of compromise can be achieved by exploiting it? How does the vulnerable product's developers react? How long does the vulnerability remain unaddressed? What is required to mitigate or eliminate that particular vulnerability? How does this affect the overall availability and management of the system(s) involved?

These issues go beyond a single vulnerability or a smug "I told you so." And they go well beyond the scope of this topic.

Re:Enough Already

[tshak]

You glossed over the entire point. Most serious IT departments don't care about the "hot off the compiler" patches because of the lack of testing involved in said patches. So, MS releases stuff just as quickly, but they don't release to the public until the quality has been assured. With OSS, sure, you have the option of installing a pre-Alpha patch, but I wouldn't say that makes OSS inherintly more responsive or secure.

Re:Enough Already

[_Sprocket_]

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.

Its a tough choice when one has to decide which is the bigger threat: the vulnerability or the patch. This is one of the issues with Microsoft infrastructure. There is a history of hotfixes and servicepacks being detrimental to the systems they're supposed to be improving.

It does little good if a hotfix is released quickly to fix a vulnerability when that hotfix itself could be more damaging than the vulnerability.

Re:Enough Already

[_Sprocket_]

See, Microsoft has a reputation, and since they actualy sell software and support they have a responsibility to their customers to test patches before they offer them as safe.

Yes. Microsoft has a reputation. And part of that reputaion is publishing hotfixes and servicepacks that have been unstable.

There are also companies who sell products and support contracts based on Open Source software. They also have a responsibility to their customers. And they work with the Open Source community to accept code, review that code, and if acceptable work it in to their offering.

One interesting point is the idea that a "script kiddie" is publishing a patch. This completely ignores the actual process of peer review involved in Open Source development (not to mention the abilities of project developers).

Re:Enough Already

[rseuhs]

Don't get me wrong

Well you ARE WRONG.

I won't upgrade my server, because I don't give a rat's ass about a "maybe if you do this and that and if 10 things coincides somebody might start a DOS attack" - bug like this.

But I would care about the numerous IIS-bugs that LET YOU TAKE OVER THE MACHINE - oh wait, I do care, that's why I don't run IIS in the first place.

Re:Enough Already

[gilroy]

Blockquoth the poster:

Most serious IT departments don't care about the "hot off the compiler" patches because of the lack of testing involved in said patches

I'm not in IT, but I'd have to see this backed up with solid numbers before I'd believe it. Most of the IT people I know want the holes plugged quickly, and are willing to use early software to do it.

Re:Enough Already

[jeremyp]

I agree the DoS attack is less bad than a total compromise, but it can be bad enough. How would the people at Amazon feel if all their web servers went off-line simultaneously for a couple of days?

Re:Enough Already

[coolgeek]

Fortunately though, patching *nix systems is *NOT* a full time job.

Re:Enough Already

[coolgeek]

Back when attrition.org used to map defacements, the curves looked almost like the netcraft curves for installed based. A closer look revealed that the big curve on the attrition graph had "IIS" on the legend, whereas the big curve on the netcraft graph had "apache". IMO, that's the real reason to avoid IIS - accounts for 2x the defacements on 1/2 the installed base. Yes, my information is a bit old...my call is it has not changed significantly. BTW if anyone can help clue me in on whom has taken to archving/logging website defacements after attrition gave up, I'll appreciate it very much.

Re:Enough Already

[0x0d0a]

I'd be more willing to believe that people would play nice with the Apache team than that they would with MS.

Not enough time!!

[dpete4552]

Hey, it's not Apache org's fault that the bug is around. If those damned security news sites wouldn't release the exploits so soon then it wouldn't be a problem. It's those irresponsible bastards that are the problem here. Sheesh, the nerve.

A bug in open source code?

[Anonymous Coward]

That's unpossible!

Re:A bug in open source code?

[TedCheshireAcad]

(-1): Obvious.

Useless bug announcements-- My turn!

[rocjoe71]

The Rocjoe Institute is reporting that under some conditions, Windows *may* crash...

It's still better than IIS

[Anonymous Coward]

Despite the existence of a flaw, it's going to be less serious than a comparable flaw in IIS. No, I'm not an anti-MS bigot; Apache typically runs an an unprivledged user. Thus, you can't root the box because of this flaw. If it were IIS, you'd have system level privledges.

Re:It's still better than IIS

[Wonko42]

That's great and all, but aren't you forgetting the Win32 port of Apache, which runs under the same SYSTEM user as IIS? Cough, cough.

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....

Re:Apache team not trusted

[fatphil]

From

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

to

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

is _not_ a fix. It's a total kludge. If a variable can contain a value that exceeds the range of its type, such that it has a different value when cast to unsigned type, the _the variable is of the wrong type_, and _that's_ the problem that needs to be fixed.

This is nothing but lousy Elastoplast.

FP.

Re:Apache team not trusted

[DNS-and-BIND]

ISS X-force regards themselves as Big. Really Big. They are as prickly and egotistical as a U.N. Commissioner, or a British aristocrat. And, like any elites, ISS is in such a position of power as to require toadiness from those who want to traffic with the X-force. Those who don't dance to ISS' tune can expect a frosty reception and official snubs.

Re:Apache team not trusted

[MarkusQ]

You're an idiot.

The compiler generates different code depending on whether it's comparing signed or unsigned values. Typecasting isn't converting anything, it's just telling the compiler to use an unsigned comparison rather than a signed one.

You appear to have missed his point. If the variable contains an unsigned value it should have been declared unsigned in the first place rather than casting this one use of it. Otherwise any other present or future uses may be in error unless they too are cast.

You may want to read things over more carefully before calling someone an idiot.

-- MarkusQ

Re:Apache team not trusted

[Tony-A]

The compiler generates different code depending on whether it's comparing signed or unsigned values.
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:Apache team not trusted

[coolgeek]

I must say parrotting chatter from the apache developer list into the form of a security advisory is what I consider to be actions worthy of the elite.

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....

Impact on *nix platforms

[jukal]

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.

Re:Impact on *nix platforms

[wytcld]

From the part you quoted, it looks like 32-bit *nix doesn't do anything much here but have a child (started for the request anyway) die - so the DOS potential is all that's there, and it's not there any more than from any other bogus request, right? Intel(AMD)/Linux folk just don't have a worry here?

Re:Impact on *nix platforms

[Evro]

This could allow arbitrary code to be run on the server as the user the Apache children are set to run as.

Oh no! User nobody is wreaking havoc!

Considering that nobody doesn't even have a login on my box, I don't see how this compares with the root-o'-the-week for IIS.

Re:Impact on *nix platforms

[jukal]

> Oh no! User nobody is wreaking havoc!

Wake up. Ever seen what happens when you break the ice, with tiny little hole? User nobody will just fall in the bottom and come back as root (berserk mode) - when you get local, root exploits are easy to find.

Re:Impact on *nix platforms

[0x0d0a]

This could allow arbitrary code to be run on the server as the user the Apache children are set to run as

Of course, thanks to suid and chroot, this doensn't give an attacker much.

The secret is Apache+UNIX, not just Apache.

Now, as for IIS...

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.

-----

Re:ISS patch is not complete

[Old Wolf]

You correctly identify that the ISS patch can leave the problem there down the track ... but then your solution does too !

The problem you have identified is that there could be code further on that references bufsiz (which I presume is a signed int). Therefore the solution is to either make bufsiz an unsigned int, or (if this is not possible), create another variable which is an unsigned int. This would require an analysis of all code that uses bufsiz, to discover the implications of changing it from signed to unsigned.

Without looking at the full source, I don't know whether "len_to_read" is signed or unsigned, but in either case your suggestion does not help, as your cast will get overridden by the type of len_to_read (eg: after int x; x = (uint)(-2); x is still a signed int and eg. (x 0) will be TRUE.

The cast on the comparison does affect the comparison because it changes the range of the quantity involved.

Re:ISS patch is not complete

[jeremyp]

I haven't looked at the code, but it seems to me that the patcher thought that bufsize is of type int i.e. 32 bit signed value and that for large values of bufsize the comparison would break. The questions that form in my mind are:

Is bufsiz an int? If I had been writing the code I would have used size_t. If that is the case, the patch has no effect on any platform with a reasonable definition of size_t which is usually defined as unsigned something.

Is r->remaining an int? If so, the patch should cast r->remaining too (or instead). If the signedness of the two quantities conflicted, it should have been obvious because the compiler would have generated a warning.

On a 32 bit machine, for the patch to change the behaviour of the comparison, bufsiz has to be in the range 80000000 to FFFFFFFF (in hex). I ask myself if it is reasonable to have a buffer whose size is apparently somewhere between 2 and 4 gigabytes.

Double standard

[bluegreenone]

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.

So your company publicizes a bug for IIS, you're a hero. Publicize one for Apache, you're now "uninformed and questionable"? Geez.

Re:Double standard

[Builder]

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.

Re:Double standard

[bilbobuggins]

So your company publicizes a bug for IIS, you're a hero. Publicize one for Apache, you're now "uninformed and questionable"? Geez.

I assume you're new to /.? You're in for a long ride my friend...

Re:Fix for 1.3.x tree?

[cliffwoolley]

Updated releases of both 1.3 and 2.0 that fix this problem will be released VERY shortly.

Re:Incoming

[iCharles]

I think there is more than a little merit to the point you are mocking.

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:Fix for 1.3.x tree?

[jukal]

> 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.

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!

Re:What happened to disclosure lead times?

[sean23007]

Your post makes me wonder: would you still be so worried if you didn't know about the vulnerability? I mean, if ISS had waited, the vulnerability would still be there, and all your servers would still be hackable, but you would be sleeping like a baby. And perhaps there is an ever bigger, more dangerous vulnerability in Apache or in some other program that you use, but you don't even know about it yet. If you suddenly become so paranoid when you hear about a vulnerability, how can you not be just as paranoid when you don't know specifically about a bug, but can be reasonably sure that it's there? I'm just wondering.

Re:What happened to disclosure lead times?

[Builder]

The problem is that when the vulnerabilities are announced, every script kiddie in town gets on the wagon and starts trying to pull servers down. If ISS hadn't announced the vulnerability, yes it would still have existed, and yes, I would still be sleeping at night.

Every time a new vulnerability is announced I start seeing the scans at our firewalls. FTP vuln -> shedloads of attempts at port 21 of every IP we answer for, even though we don't run any public facing FTP servers. Same for the SNMP vuln and every time a new IIS malformed string attack happens, we start to see it in our logs.

At least let us patch before telling the kiddies that we're possibly open to bad things :(

Re:What happened to disclosure lead times?

[kigrwik]

> Yes, that's right. The people saying ISS shouldn't have
> 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
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 ?)

Re:Fix for 1.3.x tree?

[caluml]

I am running Apache 2.0.36 and PHP 4.1.2 at the moment. It's stable enough, and quite easy to install.
Install Apache from source, then configure PHP with --with-apxs2=/path/to/apache2/bin/apxs and install.
Do the x-httpd-application .php thing in the conf file too. Search on Google if I'm none too specific ;)

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.

Most can wait for a patch

[Lxy]

From the ISS article:

"X-Force has verified that this issue is exploitable on Apache for Windows (Win32) version 1.3.24. Apache 1.x for Unix contains the same source code, but X-Force believes that successful exploitation on most Unix platforms is unlikely."

Sounds to me like it's nothing more than your basic overflow. While the article from Apache mentions the possible execution of code, I think they're referring to the Windows platform. Since all daemons have full security (root) on Windows, it makes sense that an attacker could run malicious code on a Windows machine. With *nix, Apache runs as nobody (by default, anyway) so attackers can't run any code as root, greatly reducing the amount of damage other than a DoS.

It also mentions that the overflow consumes more resources on Windows, since on *nix it's only a child process restarting rather than the ENTIRE process restarting.

Since there's no proof of concept issued yet, it's unlikely that a widespread attack will occur before a patch is issued.

Re:Let the spinning begin!

[jonabbey]

There's no point in spinning this, nor any real need. It's a bug, it has specific consequences cited in the story, it should be fixed.

Spinning would be to point out how few remote exploits have been discovered in Apache over the last 4 years compared to IIS, and the fact that Apache's exploit count (if this is exploitable) is not zero doesn't mean that it's not still a whole lot less so far than IIS.

You shouldn't run Apache as Nobody

[Anonymous Coward]

Oh no! User nobody is wreaking havoc!

nobody doesn't even have a login on my box

Too bad.. on most systems, the 'nobody' account has WAY too much power to run daemons. Running daemon processes as 'nobody' is a security faux-pas. The 'nobody' account should only be used by NFS (NFS maps 'squashed' userIDs to nobody.)

For every daemon running with 'nobody' permissions (or any shared 'daemon' UID), the security risk increases exponentially, as a flaw in one daemon means access to the process data of all of the others.

Each daemon should have it's own UID, with file permissions set accordingly, ie. write access to the pid and log files, and usually nothing else, not even /tmp (if it needs a temp folder, it gets it's own.)

Re:You shouldn't run Apache as Nobody

[Tom7]

> For every daemon running with 'nobody' permissions (or any shared 'daemon' UID), the
> security risk increases exponentially, as a flaw in one daemon means access to the process
> data of all of the others.

That's not exponential, that's quadratic.

Re:You shouldn't run Apache as Nobody

[Electrum]

Each daemon should have it's own UID, with file permissions set accordingly, ie. write access to the pid and log files, and usually nothing else, not even /tmp (if it needs a temp folder, it gets it's own.)

That's why you set the sticky bit on /tmp. Temporary files that should not be read by other users are created without world read permissions. The sticky bit prevents other users from modifying files that they do not own.

Re:It's called "Full Disclosure"

[neoThoth]

I see your point but Microsoft's IIS dev team and Apache's dev team are two entirely different animals. Respected security firms generally have the courtesy of advising the vendor first and if they don't get a response will release the bug to the public. In this case however it would appear that ISS wanted to get the publicity that NGS software would have received. Here is an excerpt from their post to Bugtraq (referenced in the parent post)

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:Incoming

[gilroy]

Blockquoth the poster:

However, I fail to understand how this is really better, other than the fact that some "beta" code was released "in hours".

Because finding a new vulnerability in the patch is no easier than -- and often much harder than -- exploiting the known vulnerability. Sure, the code is probably dashed off, but the window of opportunity is small. No one will be discussing/disclosing problems in the patch, because they'll be fixing them ('cause they can, 'cause they have the source... get it?) Meanwhile, the patch at least blocks the widely-distributed flaw and restores crackers to square one.

Contrast that to the slower model espoused by proprietary systems. Sure, the code might be more bug-free when released -- although I'd want to see actual stats on that -- but during the intervening eight weeks, millions of boxes are sitting with their ports wide open.

Too good

[selectspec]

From the official announcement:

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?

Re:slashdot.org should be renamed spinroom.org

[msaavedra]

Because of you're low ID, I assume you are not a troll, but you seem to have some misconceptions about this. This is not a linux bug, it is an apache bug. No 32-bit unixes will get rooted as a result of this, though a DoS is possible. Windows and 64-bit unixes could be vulnerable to a serious exploit, if apache is running as a privileged user, is not chroot'ed, etc. I think most 64-bit unix admins will be able to manage the problem until a good patch is available. One can only hope that there aren't too many people running apache on windows.

Re:slashdot.org should be renamed spinroom.org

[_Sprocket_]

How long will it take before this is exploited? Then how many servers will get rooted because they haven't installed a patch?

I'm not sure why you're so eager. This isn't the first time we've had a chance to compare exploitable conditions in various platforms (Linux included). Unless you're expecting to see a difference reflected by a wider adoption of Linux by less-and-less technically savvy users?

You misspelled mormons.

[unformed]

you're a bunch of immature mornons
the middle 'n' should be an 'm'. No harm done, however, ;)

IIUC

[rjamestaylor]

If I understand correctly, my i686 boxes running Linux are vulnerable to the DOS attack using the invalid remote request IF the default "chunk encoding" response is enabled. But I'm not vulnerable to the stackoverflow remote vulernability because I (1) don't have a 64 bit processor and (2) don't run Windows.

Question: where do I change the default "chunk encoding" response to an invalid request?

Re:IIUC

[shogun]

Well about the only way you could realisticly disabled chunked encoding off the top of my head is force the server to only support HTTP 1.0 rather than HTTP 1.1 with a directive such as:

BrowserMatch "*" downgrade-1.0 force-response-1.0

Chunked encoding is generally used by HTTP 1.1 when the server does not know the total size of the data to be sent, ie dynamic cgi's and the like and will just keep sending it in chunks until it is all sent.

Re:IIUC

[Electrum]

Well about the only way you could realisticly disabled chunked encoding off the top of my head is force the server to only support HTTP 1.0 rather than HTTP 1.1 with a directive such as:

That's wrong. The bug involves chunked encoding on requests, not responses.

Re:IIUC

[shogun]

Really? Maybe I should take a closer look at the advisory, I didn't know that chunked requests were even possible. Everyone else disregard my above suggestion. (Unless you really want to turn off chunked responses for some other reason) ;-)

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 .)

Apache means quality.

[rice_burners_suck]

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.

ISS Responds

[btellier]

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...

[HopeOS]

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

Official Apache Project Security Advisory

[dananderson]

The official Apache Project security advisory is at http://httpd.apache.org/

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 ]

Re:Scuse me

[Old Wolf]

Judging by the Apache report, it sounds to me as if the faulty code will not just copy the request over the end of the stack, but will do it in such a way that a 32-bit Linux generates a segfault before it gets to run any of it.

Windows handles memory segmemtation differently from Linux (I assume), so you can't compare the two on that count.

For a more detailed explanation I guess you should grab the faulty source in question and see exactly what the exploit is doing.

Re:don't believe the FUD

[Old Wolf]

riiight. so if a large commercial organization like ISS can't even identify the problem, a backyard script kiddie will be able to identify it and generate a request which exploits it, and then either find a 64-bit apache 1.3 (yeah right), or write some code to try and work in windows without crashing.

Anyway, I didn't think there were any Windows sysadmins that knew what security patches were?

Open vs. Closed source

[SamMichaels]

I think everyone needs to think about this before spouting more nonsense.

Putting aside the issue of ISS releasing it too early or the amount of bugs MS products have...

Since Apache is open source, ANYONE can look at the code and do some debugging. We don't have to wait for a coding team to code it, a debugging team to debug it, a compiling team to compile it, a testing team to test it....

Doesn't open source speed up the entire process since any amount of coders can do the patching? I would assume that the Apache team already has a boatload of patch candidates sitting in their inbox right now.

The true nature of open source is the fact that MANY coders can review the source. I'm sure a million bugs were PREVENTED already because some guy out in Kansas said "hey dude...you don't want to do it like this. try this..."

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."

Re:slashdot.org should be renamed spinroom.org

[_Sprocket_]

I think the worms attacking rpc.statd have already proven just how many leet Linux users there actually are out there.

Yet those worms have been contained fairly quickly when compared to the life span of worms designed to attack Windows systems.

The only thing funnier...

[DarkHelmet]

would be if Slashdot was hacked and this is the story that the hackers came up with :)

Official CERT Advisory CA-2002-17

[dananderson]

CERT Advisory CA-2002-17 Apache Web Server Chunk Handling Vulnerability is at http://www.cert.org/advisories/CA-2002-17.html

Personally, I think, for UNIX (maybe not Windoz), it's only a DOS vulnerability, but it wouldn't hurt to upgrade once a STABLE, TESTED fix is out.

Heh.

[autopr0n]

IIS remote code exploits every day, and in all this time all we ever see for apache is a potential Deinal of Service.

Nice :)

Re:slashdot.org should be renamed spinroom.org

[sheldon]

Like I said... Let's rename slashdot to spinroom.org. Heh.

Anyway, thanks for a good chuckle. :)

Re:slashdot.org should be renamed spinroom.org

[Tony-A]

The spin from the linux camp on this one has been pretty funny to read. :-)
Yep. IIS holes are more anoying (logs full of CodeRed/Nimda) than Apache exploits.

by Second_Derivative (#3719346)
"I've already created an exploit that causes tons of children to crash and tested it against my server. Effects are negligible. So much for a DoS attack."

OFFICIAL STATUS UPDATE (Re:Fix for 1.3.x tree?)

[cliffwoolley]

OKAY, HERE'S THE OFFICIAL WORD FOR THE NIGHT:

1.3.25 and 2.0.39 have been tagged in CVS. Both versions have the vulnerability fixed. They will be released first thing in the morning.

Re:Incoming

[jeremyp]

I concur. In fact in some ways the NT security model is superior to the *nix model. For example, on any Unix box, if you want to start a server listening on any TCP port below 1024, you have to run as root at least for a short period of time.

The argument about services on NT is a red herring. A service is merely the same thing as what *nix users would call a daemon. They only look special because NT provides a (graphical) user interface to manage them with which includes btw a way to specify a user to run as.

Re:slashdot.org should be renamed spinroom.org

[Gleef]

sheldon writes:

The spin from the linux camp on this one has been pretty funny to read. :-)

Speaking as someone who is generally in the Linux camp, I have to agree. Yes, Apache is superior, yes, Windows is more vulnerable, that doesn't change the fact that there is a security hole and lots of production machines need to be patched. I don't care about how great Apache is, or the "I told you so's" from the MS apologists. I'm more interested in discussion on how bad the vulnerability is, workarounds to use until the patch is available, and tests to make sure the patch works.

It looks like one workaround is to upgrade to 2.0.36, the bug is still there, but according to the the advisory, in Apache 2 it's only a partial DoS attack, rather than the Compromise / Full DoS (depending on platform) it is with Apache 1.3. Even with the upgrade, you need to babysit the server for attacked processes.

How long will it take before this is exploited?

Apparently It's already happening, though this report is unconfirmed and possibly a troll (stop Apache running to prevent any DoS??? All the DoS does is stop Apache from running).

Then how many servers will get rooted because they haven't installed a patch?

Probably not many, it's only exploitable that way on Apache 1.3.x running on Windows and 64-bit Unix systems. I don't know actual statistics, but I think it's safe to assume that the plurality (if not the majority) of Apache installations are 1.3.x running on 32 bit Linux and BSD platforms.

Re:slashdot.org should be renamed spinroom.org

[coolgeek]

I think perhaps sheldon caught a major resentment when his mother was abducted and later murdered by a gang of Tusken Raiders, and rather than dealing with it, he has turned to the dark side...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Fix available: 1.3.26

[dananderson]

Apache 1.3.26 is available which is supposed to fix the buffer overflow problem.

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/

Re:Incoming

[0x0d0a]

Maybe the patches are beta, but I rarely see a string of patches to patches.

Re:slashdot.org should be renamed spinroom.org

[TedCheshireAcad]

I'm not sure why you're so eager.

Leet kiddie alert.

mod_ssl and Apache 1.3.26

[dananderson]

Try ./configure --force --with-apache=/your/path/to/apache/src

Rolf is pretty good with quick patches. I would just wait a day or two. The bug is only a DOS, for most platforms it seems.