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

Oh oh

[LinuxCumShot]

Time to get more eyes on the code.

Re:Oh oh

[Anonymous Coward]

I don't know anything about the Apache architecture and as well I already have a full time job. I also wouldn't be getting paid to look at it, so what's the point again?

News finally

[Anonymous Coward]

Oh wow... Looks like slashdot finally decided to post some new news! Or is this just a 4 year old vulnerability that the editors decided to post again?

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

[blashyrkh]

You were being sarcastic, right?

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

[Anonymous Coward]

Speaking of dumbasses, I'm surprised this even got posted.

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.

Re:Switch to IIS

[Skraggy]

Thats because all the the MS/IIS vulnerabilities are large enough to drive a truck through. They don't do small in Redmond.

Re:Switch to IIS

[Anonymous Coward]

I'm not exactly pro MS, but I'm getting sooo damn tired of this /. mentality.

Every article that says something good about OSS is turned into an MS bashing thread in an instant.
Every article that says something bad about OSS (for as much as those articles exist) is turned into an MS bashing thread in an instant.
Every article that says something about MS (always negative, there are no other) is turned into an MS bash... err... no, it was that from the start.
Every article that doesn't fall in any of the categories above is turned into an MS bashing thread in an instant.

But then having to read utter bullshit like this, where the roles are turned around as if OSS is being attacked for the smallest bug while you don't even hear a word about all of the really serious ones, is too much.

Somewhere else someone is annoyed because the Apache folks only got 2 hours time to respond.
That's 8 hours more than MS get in a lot of cases, but that doesn't matter - if MS find out about a newly discovered vulnerability when they're being questioned about it by a jounalist who learned about it on some anti-MS advocate's web site or forum, that's more than soon enough.

Goodbye Slashdot, I'm going to try and find if there's a slightly less biased place where I can stay up with events.

Re:Switch to IIS

[Anonymous Coward]

Compare and contrast the security track record. IIS has the worst security record of any service in internet history, worse even than sendmail and wu-ftp combined.

Strategically this will continue beacause:
1 Security was not a design requirement, so IIS is fundamentally flawed.
2. Microsoft treat security as a PR issue, not a deliverable.

As for tactical issue to hand, ISS were ill advised. They did not consult with the vendor "Apache Org" prior to release of the vulnerability. A professional omission, and begs the question "why?".

In any event, in my capacity of IT Security Manager for a FTSE-100 company, ISS have gone down in my estimation, and that will affect their sales if others share my view.

Re:Switch to IIS

[Anonymous Coward]

Excuse me, was that *thwack* the sound of the door hitting your fat ass on the way out?

Re:Switch to IIS

[Anonymous Coward]

Keep up your good manners, Anonymous Coward!

Re:Switch to IIS

[Anonymous Coward]

Uh Uh ..If there is a dangerous fire burning up your pile of wet wood in the backyard, let me know
and I'll put it out with gasoline.

Please get a life on another planet a few galaxies away...

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

[Anonymous Coward]

There's a difference between an "admin" and "someone who installed some software".

There's also a difference between "Linux" and "something that works".

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

[ictatha]

From the "security announcement":

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

This is not meant to be a "You're wrong" statement. Of course, as you said, all admins should do their job and apply patches, etc. No matter what platform they use.

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

[zootread]

You might be able to, at best, use this vulnerability for DOS attack. In comparison to IIS holes which allow the attacker to take over, this is trivial.

What's worse: a web server going down for a little while or a web server being completely compromised and attempting to infect clients (many of which have vulnerabilities themselves) with viruses/worms while logging all credit card transactions and sending them to a third party?.

Re:Enough Already

[Anonymous Coward]

I have a hunch that FreeBSD 4.5 system running 1.3.23 and Apache is vulnerable to this attack from an incident a couple of hours ago on one of our servers.

Complete Apache segmentation fault and server non-responsiveness for a certain amount of time to anything. Had to order a remote reboot for the first time since the server was installed, although the machine did recover after I ordered the reboot and the reboot was actioned.

I can only assume that the two things are connected, and that there are bad guys out there already exploiting this security fault. A new release cannot be released quickly enough.

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

[looseBits]

Well, in Apache's defense, it does seem like a very trivial bug. If it were an IIS bug, it wouldn't even be worth mentioning.

This is one of the worst bugs to come out of the Apache SF in a while, look for an equivilent in IIS - when an HTTP 1.1 GET request is sent on Tuesdays, your server will blow up just after e-mailing your mother all of your porn.

Re:Enough Already

[quasi_steller]

I compleatly agree with you. Many people in the free software community sometimes loose site of the fact that free software has problems too. I love the free software (open source, whatever you want to call it) movement and I believe that this vulnerability could show the strength of the open source movement, if it is delt with correctly. If bugs are found and fixed quickly with no obfuscation (as has happened in the past with the company we all love, note sarcasim) then then one of the strienghts of free software will shine through.

Re:Enough Already

[smittyoneeach]

most security researchers withhold their reports until the vendor has a patch ready. Responsible disclosure and all.

And we can trust the serious thieves to engage in responsible disclusure and all, as well.
But if you discovered a vulnerability that had potential for $eriou$ exploitation, would you even say anything?

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

[Anonymous Coward]

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. Of course joe script kiddie down the street can "publish" a "patch" for Apache 5 minutes after the expliot is out, but that doesn't mean I'd install it and neither should you.

Re:Enough Already

[stevey]

I find it interesting that within one week we had vulnerabilities made public about both IIS and Apache .. both in the same area: Chunking

I wonder if the discovery of the IIS hole prompted the investigation? If so that's a good thing - and a good reason for sensible disclosure.

Re:Enough Already

[Anonymous Coward]

It doesn't make it more secure, but it is *certainly* more responsive.

You have to PAY Microsoft to get access to their patches early, whereas as soon as a patch exists for free software, you can examine and try it yourself.

You don't consider that more responsive?

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

[loginx]

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?

--------

Well this at least shows that the feeling of
slashdot people about the people at ISS-XForce
posting "advisories" and "announcements" based on
half fiction was founded after all...

Also, system administrators of any platform,
especially 64Bit platforms have the option to

browse through the apache CVS code where the
security risk has been eliminated and patch
their own apache, or simply disable chunk
request responses, still in the source.

Once again, I really don't think you have this
option if you decide to run an IIS server, which
has bigger issues with the same problem (HTTP
requests fragmentation).

Re:Enough Already

[triptolemeus]

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.

Hmmm... so even when it comes to a piece of real *nix software, the best way to exploit it, is to start it on windows.

Re:Enough Already

[Sysanalyst]

Forgot an interesting, but important point there -- at least Unix users have had true 64 bit option open to them for quite some time. It is all well and fine to point out the fatal flaw (I am one of the affected 64 bit users, and it is important to me), but I wonder how much better throughput I have had over the years by using a 64 bit Unix OS vice the less than adequate solutions from ms.

MS stuff is fine for the home, and office computers for people who could do most tasks with a 286 if the ms code weren't so bloated (remember when word had most of the same features, but ran off of two 5 1/4" floppies?). Yes, it looks nice and is easy for non-computer people to use, but it is really, really difficult to use in a large system setting -- needs too many reboots, too many additional admins, and is too hard to deal with the crash, restore and pray scenario.

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

[John Sullivan]

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

Most serious IT departments may not actually install available patches the very second they come out, but they sure as hell want the available options on the table as soon as possible. They need to make an assessment of the risks, both of the bug and the fix, and decide their own strategy and timescales. MS delaying release except to a privileged few *does* negatively impact the rest, by reducing their choices and forcing a minimum timescale where they may well have decided to patch more aggressively.

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.

Re:Enough Already

[Anonymous Coward]

That funny. How many times have hotfixes not screwed up previously applied patches etc.. Oh well.

A lot of noise?

[rector]

"Useless bug announcements" are a special topic. May be, some bugs appear intentionally to make a lot of noise of it?

now lets' see...

[slayer99]

I bet this will be patched a little quicker than the last IIS vulnerabilities :)

Incoming

[tiltowait]

I can just see the "and what if this was IIS, how would you be commenting with snide remarks" trolls now.

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

[Anonymous Coward]

While I agree with your opinion on the arguments presented by open source advocates, I didn't agree with your comment that just because Microsoft is deployed more than *nix, that it will be attacked more.

Actually, Apache is the most common webserver in place, not IIS. So, following your argument, more people will be going after Apache and not IIS...

Re:Incoming

[Anonymous Coward]

People attach IIS and Windows boxes because it the path of least resistence.

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.

Re:Incoming

[javahacker]

The difference is that Microsoft IIS runs as a service, and any exploit that lets you run code lets you have full access to the machine.

Running Apache as a process with relatively few permissions (certainly not as root) means that the most that can happen is a relatively minor problem, rather than having someone control your server.

The problem with IIS is not just the code being buggy, since any code could have a problem, it is the fact that any compromise of that code gives the IIS permissions (basically root or administrator) to the person breaking into your machine.

This is what doesn't happen on a well run *nix box, but does happen under Windows/IIS. The fact that the exploit allows full control of your machine is why the IIS exploits are so serious. Apache has not has a root exploit found in a long time, making problems with Apache less serious, however often they may be found.

The reason crackers go after IIS is how much control they get of the machine, making it much more worth their efforts.

Re:Incoming

[Anonymous Coward]

You know that it is possible to set IIS to start up as a different user, and deny that user permissions to most everything on your system. I am really getting tired of these complaints about this and that are insecure under the default setup of Windows. I find the default setup of RedHat Linux no more secure (running bind, rpc.statd etc.) than I do a default install of any Windows server. The same problems was present with code red. It's like rule #3 in the NT adminsitrator's guide and people didn't even bother to disable the extensions. If you put the same amount of time into policies on your Windows box as you spent dinking around with configs and compiles on you Linux box, your Windows box would be just as secure.

Re:Incoming

[alfaiomega]

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.

Are you trying to say that Apache HTTPD is not widely used? (Sorry, if I have not understood you)

Re:Incoming

[Anonymous Coward]

One of the reasons all crackers et al. go after Microsoft product

I would like to kill this myth once and for all. I'm going AC for this, so here goes...

I'm an ex-cracker that was in a small-to-medium cracking group. How good were we? On a scale of 1 to 10 we were probably an 8. On EFnet (where the majority hang out.. simply because there are no pansy services and it is a dog-eat-dog environment) our small group was good enough to mess with the larger groups (i.e. we could take their channels). Anyhow, I know what crackers exploit and what machines they exploit. They do NOT crack Windows. Screwing around with Windows users was just something we did when we got bored. We would use stupid script kiddie prepackaged exploits like sping, etc., etc. When we got serious and needed actual machine resources to do actual damage (i.e. take channels, take out people via DoS, etc.) we went exclusively for *ix servers. Many were Linux. While Windows was easy to DoS, you would never catch us using WindowsNT. Simply because it was foreign and too damn hard to get into. There are literally thousands of idiot *ix admins. We had cracked accounts for months. Infact, I'm willing to bet some even still work today. A really bad thing happened later though. Members started doing really bad shit (i.e. stealing huge files with hundreds of cc#s). We all parted ways then.

Here is a little food for thought: When a *ix server has a security breach, it is typically because of ignorance on the admin's part. When a Windows server has a security breach, it is typically because of ignorance on one entity's part: Microsoft. Which brings me to this question: would you rather have many ignorant *ix admins managing your data, or would you rather have many ignorant admins using software which Microsoft makes secure? Windows is designed for ignorant admins, so that is a given. To be perfectly honest, I am very weary of giving my cc# to any *ix machine. Especially after seeing how easy it is to obtain plaintext databases with cc#s. But maybe that's just me...

Oh, and if you're curious as to what purposes *ix is needed and used for, here is a short list:
IP spoofing
DNS cache spoofing (old bind bug, IIRC)
packet sniffing
CPU usage (using cracked machines to crack more machines.. what genius)
DoS
DDoS (need many different *ix servers)
IRC, etc. hijacking purposes
..and of course, today credit card theft and fraud via internet is extremely simple

This is a very short list, btw. You would be surprised what one can dream up when bored with access to multiple machines connected to very fat pipes.

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

[0x0d0a]

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

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.

Re:Not enough time!!

[Anonymous Coward]

I fully agree. Security sites, before they shoot out the vulnerability post and then, eventually, contact the author(s) for notification. A more wise policy would be to notify author(s) a few ( 1..3 ) days before the announcement to give them time to release patches. Usually it is not a matter of days but of hours ...

Re:Not enough time!!

[dpete4552]

http://jscript.dk/unpatched/ -- Some of those have been out for months. Microsoft has been contacted. Yet no patch? Hmm

Or how about this article from June 13th http://slashdot.org/article.pl?sid=02/06/13/041720 6

"...eEye Digital Security discovered the flaw in mid-April but it wasn't announced publicly because of an agreement with Microsoft."

A few days, a few hours, rofl. Riiight...

A bug in open source code?

[Anonymous Coward]

That's unpossible!

Re:A bug in open source code?

[Verizon Guy]

Hahah, classic Ralph Wiggum quote right there...

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

Re:Useless bug announcements-- My turn!

[Old Wolf]

Sounds like an improvement, not a bug..

Finally...

[RAMMS EIN]

Good to know that some Grey Hats are working on finding holes in Apache, too. That way it can stay ahead of IIS, which gets patched on a rather regular basis.

echo Patch apache >> todo.txt

Debian

[mackstann]

so how long before i need to apt-get update && apt-get upgrade? :)

Re:Debian

[Anonymous Coward]

Debian has a really cool command:

apt-shutthefuckup

We don't care about your distro.

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

[Anonymous Coward]

Wrong - most IIS vulns (Since IIS4) execute as IWAM_MACHINE since the default process protection is Pooled not Process. Pooled apps run in a dllhost process running as IWAM_MACHINE.

Please take to the time actually know something before posting.

Thanks

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.

Re:It's still better than IIS

[Dan512]

Huh? By default the web hosting process in NT and Win2K run as a user in the Guest group.

Do many people put IWAM_ and IUSR_ in their Administrators group out of lazyness? Yes. Is that the fault of MS? No.

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

[Anonymous Coward]

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.

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

[Anonymous Coward]

The usual method ISS takes is to go through CERT.org, and coordinate with the "vendor". They wouldn't skip the process simply to "spite" someone.

The problem with bug reporting is that there is a miscommunication between both sides. For example, a hacker named K2 released the IDS evasion tool called ADMmutate, and showed it at DefCon evading ISS's RealSecure. The thing is, ADMmutate doesn't evade RealSecure -- there was a completely separate evasion of a single IMAP signature that was evadable with/without ADMmutate. ADMutate just happened to use that one IMAP signature to demonstrate its polymorphic shellcode. So you had a situation where one side was claiming a problem and the other side claiming there wasn't: both sides were right, both sides were wrong.

Unfortunately, this sort of thing is the norm rather than the exception.

Re:Apache team not trusted

[fw3]

Unfortunately, this sort of thing is the norm rather than the exception.

It's not an new debate. Personally I can think of few excuses for not working with the apache team to have a working and hopefully tested patch available and ready prior to any public dissemination of the fault.

The reality is that neither the kiddies nor the actual writers of exploits have stumbled upon this until ISS notified them.

It is illegal to own lockpicks in all states I know of. That's an old law, while generally the US doesn't outlaw items that have legitimate uses, clearly DMCA shows that we could someday see a class of coding and analysis tools which can also be used for attack outlawed.

I can't see how ISS is helping to avoid that outcome.

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

[Anonymous Coward]

While this is not a proper fix for the real problem, it will prevent the bug being remotely exploited:

ISS X-Force response (fwd)

Re:Apache team not trusted

[Anonymous Coward]

Hmm, if bufsize contained the wrong value during the query, why is its value deemed to be okay afterwards?
Its not even nearly a fix. The problem could only be where the bufsize was initilised.

Re:Apache team not trusted

[neoThoth]

I saw a post attached to this thread somewhere stating ISS surely wouldn't withhold out of spite. In fact they simply don't trust the Apache team (specifically Red Hat).

"It may not be in my customers' best interest to let Red Hat know there is a
security vulnerability," Rouland said. "I don't consider Red Hat a trusted
third party."


How is it they can't trust Red Hat? Aren't they one of the affected vendors? Sounds like a personal issue to me.

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.

Re:Apache team not trusted

[fatphil]

I said "such that it has a different value when cast to unsigned type"

You said "Typecasting isn't converting anything"

I'm glad to see you know more about the language than the standards body.

{{{
6.3.1.3 Signed and unsigned integers

1 When a value with integer type is converted
to another integer type other then _Bool,
if the value can be represented by the new
type it is unchanged.
2 Otherwise, if the new type is unsigned, the
value is converted by repeatedly adding or
subtracting one more than the maximum value
that can be represented in the new type
until the value is in the range of the new
type.
3 [Irrelevent here]

}}}

Let me repeat that - the value is converted by repeatedly adding or subtracting ...

Sheesh, slashdot is getting stupider. Please leave and do the mean IQ here a favour.

FP.

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

Re:Thoughts on this hole

[drzhivago]

(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?

Heh, initially I read ISS as IIS, which seemed plausable as this problem relates to web servers. Welcome to acronym hell, everyone!

Re:Thoughts on this hole

[Anonymous Coward]

I'm going to go for a shit now.

And AOLserver is still unaffected

[Anonymous Coward]

You apache and IIS nancies can kiss my ass.

Who cares??

[Anonymous Coward]

Why exactly do we care about this? Everyone knows IIS is the best and most secure web server for Windoze :-p

20 Minutes Into the Future...

[Anonymous Coward]

A new vulnerability is discovered in Microsoft Internet Information Server. Five hundred Slashdotters post within 15 minutes, gloating.

Yeah, yeah, go ahead, -1 for flamebait. But you know I'm right.

"uninformed and questionable"?

[Anonymous Coward]

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.

Why is it whenever there's a bug in IIS you use it as an opportunity to bash Microsoft, but when there's a bug in Apache you attempt to shift some of the criticism and negative attention to - of all places - the group that discovered the bug?

What do you find "questionable" about the bug report? The fact that it found a bug in an Open Source product?

Re:"uninformed and questionable"?

[cliffwoolley]

The fact that it doesn't describe the entire scope of the problem. See the official announcement on httpd.apache.org to understand why.

Re:"uninformed and questionable"?

[markcox]

Looks like they've missed a (long) to (int) conversion that happens later which strips the high word and lets you have exact control over the memcpy length.

Bugs Apply To All Software

[jaxon6]

Every large piece of software has bugs. It is inevitable. The difference is that if a piece of software is written with security in mind, it will have less bugs. If a piece of software is written with backward-compatibility, ease of use, performance at any cost, etc.., it will have more bugs.

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

[Evro]

Yeah, I know, it was a joke. But this has to be at least marginally better than getting root automatically, as is the case with some setups.

Re:Impact on *nix platforms

[WetCat]

you really should be running "no-root" system, i.e. RSBAC (www.rsbac.de) or SElinux, with Mandatory Access control. There even if somebody gets root - he gets nothing - roots rights are controlled by other user - security officer and its login is separate and only be done, for example, from console.

Re:Impact on *nix platforms

[Carlos Laviola]

when you get local, root exploits are easy to find.

Not on my system. Speak for yourself, or prove your assertions.

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

Fix for 1.3.x tree?

[Anonymous Coward]

It's nice that they've fixed it in 2.0.x, but what about the (literally) millions of people who use a 1.3.x version? Are we screwed? PHP doesn't work on 2.0 yet, so upgrading to 2.0 is not an option for us. Now what?

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

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

Re:Fix for 1.3.x tree?

[AnotherSteve]

Actually, the instructions are there on the
php.net installation page. You just have to scroll down to the comments to find the good stuff about Apache version 2.

Re:Fix for 1.3.x tree?

[Anonymous Coward]

Still waiting, Cliff. Work faster, dammit!

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

[Anonymous Coward]

I believe that bufsiz is of type int and
len_to_read of type int or unsigned int.
In this case, casting bufsiz to unsigned
int is not required since such a cast
would preserves the bit pattern. This is
a dirty but valid code.

On the other hand, the first cast changes
the signed comparison into an unsigned
comparison and so is required.

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

[Anonymous Coward]

It sounds a lot like 'they're fragging Apache! boo hiss!' 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...

stop yer whinin' fool.

[Anonymous Coward]

just like any of the other companies currently using useless bug announcements as press releases.

It's called full disclosure fuckio, what's the matter can't take the heat when it comes around to you?

doesnt it saw "windows version"?

[prmths]

It claims that it's a 32 bit overflow problem - and in unices it will cause the child process to terminate. This post almost got me thinking i had to upgrade to a new version... ;)
If you're running on a sane OS, The bug seeme negligable.. so a few people will have to hit reload if they try to do funny stuff.
(It's not easy foreseeing 'issues' with dealing with a non-open or standardized OS)
isnt using a good server software on an OS that really WAS NOT made for server functions sort of like using a bandaid to cover up leporacy? (sp?)

Re:doesnt it saw "windows version"?

[prmths]

bah. replying to my own post -- but -- forgive the typos -- i swear i checked --I just woke up

Re:doesnt it saw "windows version"?

[cliffwoolley]

YOU SHOULD UPGRADE. Don't think that this is a small problem; you'd be mistaken.

Oh lovely

[sheepab]

Here come all the 'Linux death watch'/'Linux is evil' trolls with their nonsense about how Linux is more insecure than Windows. Death to all trolls!

I work at MS...

[Anonymous Coward]

...and I just walked past Bill's office. Someone was yelling "YES!!!! Oh, YES!!! TAKE THAT YOU @#$@#$%^@ PENGUIN!!! FINALLY!!!"

I just kept walking.

Re:I work at MS...

[Anonymous Coward]

No Mod points but... +5 Funny! for you my friend.

I always like how

[JeanBaptiste]

apache bugs seem rather trivial, while most every M$ bug ends with 'which could allow malicious code to be executed' or 'which could allow unauthorized access' (I know thats not verbatim but I dont feel like looking it up.)

WHAT!!!!

[Anonymous Coward]

YOU'RE NOT SUPPOSED TO TELL ANYONE!!!

Oh, sorry, I don't own that. Never mind.

-- Bill

Ridiculous!!!!

[Anonymous Coward]

Even the most casual reader of /. knows that security problems are unique to Windows and cannot exist in a Linux environment.

right?

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?

[Anonymous Coward]

If anyone from IIS is reading this, you're a bunch of immature mornons. Play by the rules or fuck off!

Hello kettle, this is the pot. You're black.

Re:What happened to disclosure lead times?

[Anonymous Coward]

What you complaining now ? I thought you liked "open" source.

Re:What happened to disclosure lead times?

[Anonymous Coward]

What happened to the lead time given to a software vendor before publishing a vulnerability ?

What happened (as far as I can tell) is that ISS found the bug, notified the Apache group. Apache said "we know, we're working on it, and will release a report when we have a fix", so ISS decided they wanted to get "First Post!" and released their advisory early.

Re:What happened to disclosure lead times?

[Yankovic]

I'm sure you meant "ISS" and not "IIS" :)

Re:What happened to disclosure lead times?

[Builder]

I love open source. But I also work with closed source. I like having a patch available when a vulnerability is announced. I get this with IIS, Exchange, etc. I didn't this time because the people who published the flaw never gave the vendor time to address it.

Re:What happened to disclosure lead times?

[Tom7]

Were you sleeping last night? Last week? Apache wasn't secure then, either. And it probably won't be even after you apply the patch.

Re:What happened to disclosure lead times?

[Anonymous Coward]

>>I can't sleep until I know they're secure.

ooooohhhh. yeaaaaa. Hey man it's just free code. it's not like you pay for the patches or anything. At least they published it, I can think of many worse senarios...

sweet dreams.

Re:What happened to disclosure lead times?

[Anonymous Coward]

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.


You're the guy whose picture they used for the cowboy on the cover of O'Reilly's 'Running Linux' huh?

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?

[Anonymous Coward]

I see, so this is the inherent flaw in open source.

Re:What happened to disclosure lead times?

[SN74S181]

Your post makes me wonder: would you still be so worried if you didn't know about the vulnerability?

In part, it has to do with his reliance on 'Security through Obscurity' although you won't hear him call it that. Until ISS broadcast the bug out all over the place, it was an obscure bug known only to a limited number of folks. Now it's hanging all out and every medium-level script kiddie on the net is digging away trying to make it useful.

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.

Re:What happened to disclosure lead times?

[Anonymous Coward]

vendor? What happened to "The good thing about open source is you can fix bugs yourself?"

The hypocrisy never ends on /.

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

Details of bug

[fw3]

Reportedly advisory This is a denial of service in 32bit unix (linux, bsd), and an exploit in 64 bit unix.

Regrettable that there's no patch (yet), sites running 64 bit ought to be taking immediate steps to prevent release of data readable by the apache account. I imagine there will be som DOS-ing of the more abundant 32 bit platforms.

Re:Details of bug

[Anonymous Coward]

-1 (Redundant Karma Whore)

Pot, Kettle, Black

[Anonymous Coward]

Sorry, you can not have it both ways people. You want full disclosure? There you are then. You want to gloat and make fun of every single MS vulnerability? Fine, I think they are amusing too sometimes but be prepared to wear the shoe when it fits. Apache is not flawless, vulnerabilities will be exposed. Forget the /. headline and write up, read the advisory by ISS then make up your mind. I do not like the ISS group, but they have nothing but praise for apache in the bug submission and actually tried to provide a fix for the problem. Maybe they do have bad blood with Apache.org, it would not be the first time that OS folks clashed with commercial vendors and will not be the last. I ask you, is it better knowing the problem exists or hoping that the blackhat crowd doesn't know about it yet?

Scuse me

[Second_Derivative]

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.

Ok can someone PLEASE explain what this report is about? Can you or can you not cause a stack overwrite on x86 Linux? it says that 32 bit unices it won't work; how is the stack handling different from 'doze? it then goes on to say that 64 bit architectures can be exploited and that "Apache 1.3 on windows is exploitable in this way". Apache on windows == 32 bit != 64 bit!

Someone care to clarify?

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:Scuse me

[Second_Derivative]

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.

Mod parent down - troll

[Anonymous Coward]

The common argument that Apache is better than IIS isn't built around IIS necessarily having no bugs, but the speed at which Apache bugs are discovered and patched.

Furthermore I think his signature, designed to look like a request from Hemos to mod his message up (complete with offsite link to his website), should count as a troll.

all admins have to keep up with their patches, service packs, and whatever.

Newflash! Who the hell ever said otherwise!

Re:Mod parent down - troll

[TheRealSlimShady]

The common argument that Apache is better than IIS isn't built around IIS necessarily having no bugs, but the speed at which Apache bugs are discovered and patched.

What, you mean like the speed this most recent bug in Apache was found? Present in all versions up to 1.3.24 - that's quite some time...Do you mean that many eyeballs doesn't make all bugs shallow?

Penguin?

[Anonymous Coward]

Apache does run on other (free and non-free) OS's you know. Shouldn't he have been screaming "TAKE THAT YOU DIRTY RED INJUN!"

It's called "Full Disclosure"

[Anonymous Coward]

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?

It's not a big "ooops", it's called full disclosure, and the Slashdot crowd are usually applauding it when it's applied to Microsoft.

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:It's called "Full Disclosure"

[redwoodtree]

Sorry, you don't know what you're talking about. Security professionals spend a lot of time discussion disclosure lead times and policies. Professionals do to expose leaks before contacting the vendor whether it's Microsoft or Apache.

So don't try to play this off like all Microsoft vulnerabilities get posted before M$ is notified.

Spin, spin, spin

[The Turd Report]

Jesus, I am getting dizzy with all the spinning you OSS guys are doing.

Re:Spin, spin, spin

[Anonymous Coward]

Where's the turds? It's been awhile.

Sarcastic?

[Anonymous Coward]

Um... noooooooo.

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.

Re:Full disclosure and reputations...

[Anonymous Coward]

'Hey Cletus! Should I shot this here messenger?'

'Yeah, he delivered bad news this time.'

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:Most can wait for a patch

[Builder]

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.

The fact that you have to try and workout what they are trying to say in the announcement is not a good thing. When you're announcing a vulnerability, the announcement should make it clear what the effects are. If the effects differ from system to system, that should be clear and the impact of the flaw should be clearly described for each system.

Re:Most can wait for a patch

[Anonymous Coward]

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

Don't bet on it.. here is an excerpt from an email posted to Bugtraq by Mark Maiffret (eEye CHO)

Since there has actually been many chunked encoding vulnerabilities released lately, and exploits (for win32) it only makes sense that it will take no time for someone to develop an exploit for this Apache Win32 chunked overflow

Re:Most can wait for a patch

[Anonymous Coward]

Uh, you are wrong on several counts. Don't post misinformed crap posing as someone who knows what he's talking about; what's the point??

Insightful?

[muffel]

Huh, how is that insightful?
2+3=5. Remeber to go to the bathroom when you need to take a piss. It is usually dark at night.
Do I get a +5 Insightful now?

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 new around here?

[The Turd Report]

Every time there is a bug in a MS product the Slashdot janitors fall over themselves to be the first to say: "MS is buggy crap! Yay Linux!" But, when it is an OSS product that has the bug, they are quick to blame the people reporting the bug. Doesn't that strike you as odd?

Re:You new around here?

[Anonymous Coward]

considering the perportion of IIS bugs compaired to Apache bugs? no

Re:You new around here?

[Verizon Guy]

Yeah, and notice they never posted a story about the recent exploit in BIND 9 (which shipped in most recent Linux distros) which allows you to shut down the server. But any little Windows bug, well, it's always front page material. Funny for a site whose "supposed" major audience is Lunix lusers.

Re:You new around here?

[pigeon]

You mean, slashdot has a lot of lunix users? Lunix is the unix for the commodore 64.. (I kid you not).

Re:You new around here?

[SN74S181]

Unfortunately, to a great extent, this is a Linux fanboy site. It's sad, because some of us want it to be more than that, to talk about actual tech. We'd like to shut out the zealots from all the losting platforms (OS/2, Amiga, Mac) who've crowded into 'Linux' because it's a fairly sharp way to be anti-Microsoft. We'd like to talk about geek like embedded controllers, new tech breakthroughs, etc. etc. Sort of a 'Circuit Cellar Plus' so to speak.

Re:You new around here?

[Verizon Guy]

I wish...

Re:You new around here?

[The Turd Report]

Really? Must be what Junis uses to download all those movies he and Katz watch on his C64. :)

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:You shouldn't run Apache as Nobody

[sidster]

I think what Tom7 meant was if you have daemon_proc_a and daemon_proc_b running as user nobody and both write their temporary files in the /tmp directory (with our without sticky bit set on /tmp) if daemon_proc_b is exploited it can clobber daemon_proc_a's temporary data files and cause some "damage".

Re:You shouldn't run Apache as Nobody

[Anonymous Coward]

Nope.

Re:You shouldn't run Apache as Nobody

[Anonymous Coward]

uh, yes. Care to explain?

Re:You shouldn't run Apache as Nobody

[Anonymous Coward]

Why?

Don't point the finger at ISS.

[dave-fu]

What they did (unilaterally going ahead and releasing a bug they discoverd) is shady, but you should instead point the finger of blame at the Apache group for distributing a buggy product (IIS had a similar problem with chunking way back when... what's that cliche about forgetting history?) and, if you're the one who's pimping open source as the best thing since sliced bread to anyone who will or won't listen, point the finger right back at yourself for blindly trusting the code you're running.

slashdot.org should be renamed spinroom.org

[sheldon]

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

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

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?

Re:slashdot.org should be renamed spinroom.org

[Anonymous Coward]

I had an exploit at 19:50 hours GMT this evening. That is 3 hours ago.

This is a real exploit and the bad guys are exploiting it now.

Luckily it is only DoS, and Unix systems recover more easily than Windows, so when the fix is released, simply stop Apache running (to prevent any DoS during compile or upgrade), compile and install.

We need the fix now.

Re:slashdot.org should be renamed spinroom.org

[Anonymous Coward]

'This is not a Linux bug, this is an Open Source bug.'

Re:slashdot.org should be renamed spinroom.org

[Anonymous Coward]

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

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.

Re:slashdot.org should be renamed spinroom.org

[zaphod110676]

I'm still getting several hundred attacks a day from which ever of the worms it was that would try and execute cmd.exe among other things. Code Red, Nimda, and Sircam all came out so close together I can't even remember which is which any more.

I don't see/here about too many rpc.statd attacks. Maybe I just know good admins.......

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

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

Re:slashdot.org should be renamed spinroom.org

[TedCheshireAcad]

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

Leet kiddie alert.

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:Important - Need Gook / Geek porn

[Anonymous Coward]

Not bad, but I'd prefer some gash,if you know what I mean!

ISS posts a response

[neoThoth]

Nothing about their motive to release this without notifying the vendor (apache dev team) but sheds light on remotely exploitable aspects of this find.

----------

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

Updates

[Ace905]

Updates to this story can also be found here

Re:don't believe the FUD

[Builder]

It hasn't been corrected yet. Many sysadmins in Europe will be sitting up tonight waiting for a patch.

The only useful message on this topic

[redwoodtree]

The post above is the only intelligent post for discussion on this issue so far.

You misspelled mormons.

[unformed]

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

Yes, all we�re asking is common sence...

[dmouritsendk]

First, im not at all a legal expert. But Ill bet good money that if you found a bug in ISS and posted on you personal security homepage WITHOUT informing/communicating with microsoft first you could be in trouple.

But this is not the issue here, the issue here is security and common sence. Why would a sercurity team(with common sence =):

• Fail to talk to the people behind the software inflicted with a bug? Who knows, maybe they knew it was there, and in the process of fixing it. This is one of the senarios that MS fears about opensource, not having control over which/when bugs are made official to the public.
  
• Post information on a exploit, and how to use the exploit. When they have no solution for the bug? Crackers use thiese pages to you know? this senario is a crackers wet dream.
  
• Make millions of websites MORE insecure?
  

I dont get ISS-X Forces behavior in this case, I must admit I find them extremely questionable.

Why? think of it in this way. If that guy who found a bug in oreilys site (customer information leak thing(easy, supposedly no cc info leak=)), hadnt talked to oreily. But had shut his mouth and posted it on some security webpage, wouldnt u find him questionable?

Just my opp.

Re:Yes, all we�re asking is common sence...

[Anonymous Coward]

I dont get ISS-X Forces behavior in this case

I do - it's called "first post" syndrome - they were pissed that someone found it before they did, and decided that the only way to get bragging rights was to screw over the Apache team.

Re:Yes, all we�re asking is common sence...

[dmouritsendk]

I dont hope u are right, but that actually sounds like a plausiable senario.

Re:Yes, all we�re asking is common sence...

[bluegreenone]

Yes, I do agree to some extent about informing the developers. BUT, open source advocates are always complaining about Microsoft's security through obscurity and how open source is great because you don't have to wait 2 months for MS to issue a patch to even know there was a vulnerability. According to most open source advocates what happened is what's supposed to happen: the hole was announced immediately and users have the choice of whether to keep Apache running.

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

[Anonymous Coward]

thanks for that

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

Re:Some more data

[|<amikaze]

s/IIS/ISS/

Re:Some more data

[CounterZer0]

With that spelling, can we trust a patch will compile? :)

Re:Some more data

[|<amikaze]

Ahh!!! We definately don't want to compile IIS into apache!

ISS has tarnished themselves; badly

[fire-eyes]

None of the behind the scenes politics (or non-politics) matters here. ISS has tarnished themselves, badly.

Really bad move there, many people are going to see things from them in the future and think "Hey, these assholes again, ..."

Smooth move.

Re:ISS has tarnished themselves; badly

[Anonymous Coward]

Yeah.

They fragged Apache.

Fuckers couldn't even keep a secret. The people who were working on getting clothes on the emperor are now PISSED.

Don't they know our security needs to be protected by keeping things like this obscure? (security through obscurity)

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.

Re:Apache means quality.

[Tom7]

It's true that apache has a pretty good track record, but sadly this bug was not found through code review or anything like that. It was found using the same means available against a closed-source server: spamming the thing with malformed requests. I'm not sure a security issue is "obscure" if it's in the default configuration, either...

Re:Apache means quality.

[bigberk]

I agree. Apache has been solid for a long time, and this incident doesn't faze my confidence in the apache httpd project.

Also, this isn't really as serious a security problem as some people are making it seem. Apache does not run as root by default. Also, on 32 bit *nix'es this bug results in a dead thread, not remote execution of code. Not nearly as dangerous as past rpc/wuftpd/sendmail/bind/most-IIS-bugs ;)

Re:Apache means quality.

[MisterBlister]

Not only that but the bug was found in a closed-source server FIRST! So much for many eyes.

Re:don't believe the FUD

[caluml]

>> Many sysadmins in Europe will be sitting up tonight waiting for a patch.

Not me - I'm off to sleep now :o)
If anyone works out how to exploit it before the latest rpms and debs filter on through, I'll be damned suprised.

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

Anyway...

[Anonymous Coward]

They control their site's content. As said, there'll be great press as they will proclame themselves as the "first team" to discover and patch the issue.

Also, their site seems to be out of service. Hmmm. Slashdot effect or someone exploring the vulnerability they (supposedly) discovered?

What happened wrt the discovery and reporting

[lwillett]

I found this message and this message (from bugtraq) to be informative regarding the interesting issues here.

Re:don't believe the FUD

[Anonymous Coward]

They have already. 4 hours ago now. Segmentation fault in Apache followed by a complete DoS on the server for about 20 minutes.

I just love it ;)

[Anonymous Coward]

People can debate, argue, defend, etc all they want. I think this is a great statement for open source!

I ssh over to one of my systems with apache installed. And open up http_protocol.c and bang there it is. I can look at it, think about it, maybe even figure out how to fix it and then rebuild.

This is the true power of open source. With closed source your just out of luck and depending on someone else. This is a huge statement about the freedom and control open source gives it's users.

Re:I just love it ;)

[jasonn]

Amen! It's nice to finally have control. When I was a Microsoft ISP, I had to rely on Microsoft to 'feel' like revealing their hole then release the updated file. It was wonderful to finally actually have some level of control over my servers. I will NEVER rely on IIS for production servers again.

Set an alarm

[Anonymous Coward]

04:00:00Z

Free Software is not the same by any other name.

[jbn-o]

All spelling in context, all emphasis is quasi steller's:

I love the free software (open source, whatever you want to call it) movement and I believe that this vulnerability could show the strength of the open source movement, if it is delt with correctly.

If you love the free software movement as you claim, please take the time to learn the difference between the two movements so you won't be confused anymore and think that they refer to the same thing with different names.

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

Mod down parent post

[Anonymous Coward]

-1, Makes_Open_Sores_Look_Bad

Re:don't believe the FUD

[Anonymous Coward]

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

LOL you made a funny! I made a doodie.

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

impartiality

[v8interceptor]

Take the following situation:
A certain web server product has a security hole.

Is it open source?
"Believe it or not, reports that XXX has a certain vulnerability. Amazing, we could hardly believe it. We had tested the vulnerability TEN TIMES before running this story...".

Is it NOT open source, and perhaps even made by a certain larger corporation?
"HAH! More reports that XXX is an absolute joke, about as secure as a plastic bag. The l4m3rs at XXX corp took three YEARS to produce a patch, which is now available. The vulnerability this time allows you to take over the sysadmin's computer if he/she is playing mine sweeper..."

That said of course I would use Apache over IIS anyday :)

Re:don't believe the FUD

[Anonymous Coward]

Never r00ted because nobody ever visits it.

IIS is honestly THE big piece of CRAP, in terms of software. Your comment is just ridiculous and out of point. Grow up!

The only thing funnier...

[DarkHelmet]

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

I applaud announcement. Full Immediate Disclosure

[Anonymous Coward]

Full disclosure is the only way to let the public protect themselves as early as possible. Just because some vender and whitehat does not release info does not mean that some other blackhat hasnt already discovered it months or years ago and already uses it to gain access.

Re:don't believe the FUD

[Anonymous Coward]

if you are as perceptive of being rooted as trolled I would re-install your Windows Me distro

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.

Glass houses

[Anonymous Coward]

Thankfully anyone can fix bugs in open source software instead of waiting for the inconsiderate slowpokes in Redmond. I fully expect that hundreds of programmers are going over the Apache code as I write this, and a patch will be posted by morning. That means that that nasty little bug will be installed on servers everywhere before nightfall.

Thank god for open source.

GOOD LORD

[bobdole34]

THATS IT! Im switching back to IIS.
Id rather my entire box be freely exposed to the scriptkiddy.net then a child proc. be restarted.

lol

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:don't believe the FUD

[Anonymous Coward]

Wow! If you think that a site has to be visited in order to be rooted, you're a fool! Script kiddies everywhere are scanning networks non stop... case in point: a coworker new to Linux left his laptop running RedHat 7.0 at work for a few days as a webserver... hacked in just over two days.

Fool.

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:don't believe the FUD

[Anonymous Coward]

That's not possible. Linux is "unbreakable." Larry Ellison said so.

Re:don't believe the FUD

[cliffwoolley]

Like I said in another comment, 1.3.25 and 2.0.39 have been tagged in CVS and will be released in the morning (US eastern time). You can go ahead and grab the new versions from CVS if you're in a hurry.

Fixed in OpenBSD

[Anonymous Coward]

The issue has been immediately fixed in OpenBSD-current.

Re:don't believe the FUD

[Anonymous Coward]

Yeah,that's called bad sysadmin.

Anyway, out of curiosity (really!), did you have to reboot your windows machine anytime you patched your IIS server?

It's just a crashed process...

[jawtheshark]

Please explain me *why*? I run an OpenBSD 3.0 box as router on my DSL and it also runs Apache (that's about all it does). What is so bad about it when httpd crashes once in a while? It's not as if anybody is going to get his dirty little cracker hands on my root account?
It's just a dead process, I'll start a new one.

Of course I realise that I should patch Apache (and probably all the OpenBSD patches since 3.0), but I didn't take the time yet because I have no real clue how to do it. (Seems you have to compile from source...real fun on a P166)

Re:It's just a crashed process...

[cliffwoolley]

Not any more. A remote exploit for OpenBSD has been released on bugtraq. You're very vulnerable.

Re: Bah Windows N/T

[Anonymous Coward]

No text

IIS Configuration

[javahacker]

I know that you can set up IIS to run as another user. People don't generally do that. I don't know why it is, but the defaults are often used with IIS, in spite of documentation that says you should change it.

I suspect that *nix admins, because they have to be more motivated to learn how to set up things without all of the pretty graphical tools, are more inclined to actually do the things needed to secure their systems. Just speculation.

Like I said, IIS is targeted because there is often a good return on the cracker's time, they get to own another computer system. Crackers (especially the script kiddie variety) want an easy mark to attack.

Re:Hah, the hypocrisy...

[Anonymous Coward]

who the hell are you? really? am I supposed to look at "Linus Turdballs" and have the upmost respect for you and what you say? Hell no!

Yes, I do belive in freedom of speech, but I also believe in replying to that free speech

I've gone through your whopping 15 posts and all of them are nothing but baseless Trolls designed to make the foolish even more foolish.

You are what's wrong with the world.

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:Fix available: 1.3.26

[Anonymous Coward]

Anyone have any good work arounds for getting the new apache to compile with mod_ssl? The most recent mod_ssl will only compile with apache 1.3.24.

Re:Fix available: 1.3.26

[dananderson]

At http://www.modssl.org/ is the new mod_ssl patch for Apache 1.3.26:
19-Jun-2002: Released 2.8.9-1.3.26: Apache 1.3.26 and bugfixes.

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.

Re:mod_ssl and Apache 1.3.26

[cliffwoolley]

Not just a DoS anymore, an exploit for 32-bit platforms has been released. Please see http://httpd.apache.org/.

Already fixed

[geschild]

Due to 'due diligence' this 'hole' has been fixed. Patches are out for both 1.3.x and 2.0.x.

To all responsible sys-admins out there: go get the patch(ed version)!

(Another day, another bug squashed in under 2 days).

Re:Hah, the hypocrisy...

[getter_85]

heh, you ARE a good troll *nods*

seriously, if you want people to not make fun of your name, then don't claim that you wrote the linux kernel then, or else people will just think you're a bad parody trying to piss every linux user off

Apache decided the ISS fix does work

[xijix]

Apache has revised there posting to say that the ISS patch acctually does work.

Re:Hah, the hypocrisy...

[Linus Turdballs]

I didn't write the Linux kernel. My lifelong lover Alan Cox employed 65,536 monkeys to bang out a new operating system. Unfortunately he ended up buttfucking them all to death, being the zoeophile that he is, so he ended up hiring himself another 65,536 monkeys -- er, "Kernel hackers" -- to write it for him. I don't know where this story was supposed to be going when I started writing it, but it had something to do with Linux and homoeroticism, but now I forget... you racist pig!!

My only contribution was the "Lee Nucks" name, and the dev_homo.o device driver.

Re:Hah, the hypocrisy...

[getter_85]

what happens when I click "User #558038 Info"?

I see a little blurb about "Linus Turdballs" creating the Linux kernel.

Re:Hah, the hypocrisy...

[Linus Turdballs]

Click me harder and you'll get a thick, gooey surprise. :}
8========D~~~*

LMAO! Stop, you are hurting me!

[jasonn]

Microsoft's Technet IIS Announcements

Security Updates on Microsoft's Site

• Unchecked Buffer in Profile Service Could Allow Code Execution in Commerce Server (Q322273) Originally posted: June 26, 2002
• Microsoft Security Bulletin MS02-030 Print Unchecked Buffer in SQLXML Could Lead to Code Execution (Q321911) Originally posted: June 12, 2002
• Unchecked Buffer in Remote Access Service Phonebook Could Lead to Code Execution (Q318138) Originally posted: June 12, 2002
• Heap Overrun in HTR Chunked Encoding Could Enable Web Server Compromise (Q321599) Originally posted: June 12, 2002
• Unchecked Buffer in Gopher Protocol Handler Can Run Code of Attacker's Choice (Q323889) Originally posted: June 11, 2002 Revised: June 14, 2002
• Unchecked Buffer in ASP.NET Worker Process (Q322289) Originally posted: June 06, 2002
• Malformed Mail Attribute can Cause Exchange 2000 to Exhaust CPU Resources (Q320436) Originally posted: May 29, 2002
• Authentication Flaw in Windows Debugger can Lead to Elevated Privileges (Q320206) Originally posted: May 22, 2002
• SQL Extended Procedure Functions Contain Unchecked Buffers (Q319507) Originally posted: April 17, 2002
• SQL Extended Procedure Functions Contain Unchecked Buffers (Q319507) Originally posted: April 17, 2002
• Cumulative Patch for Internet Information Services (Q319733) Originally posted: April 10, 2002
• Opening Group Policy Files for Exclusive Read Blocks Policy Application (Q318593) Originally posted: April 04, 2002
• Unchecked Buffer in Windows Shell Could Lead to Code Execution Originally posted: March 07, 2002
• And, just because it's so funny: RTF document linked to template can run macros without warning Originally posted: May 21, 2001

I can definitely see how you may find it difficult to find all the security holes in your IIS installation. I mean, crap, after the daily inundation of security holes in the litany of Microsoft product releases, it is understandable you pay attention to the hand full of weaknesses (that typically do NOT allow root access) various Unix deamons have publically announced.