Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apache Vulnerability Announced

krow posted more than 12 years ago | from the lame-DOS-attacks dept.

Security 307

Aaron writes "Versions of the Apache HTTP Server up to and including 1.3.24 and 2.0 up to and including 2.0.36 contain a bug in the routines which deal with invalid requests which are encoded using chunked encoding. In some cases it may be possible to cause a child process to terminate and restart, which consumes a non-trivial amount of resources. See the official announcement and stay tuned here for updated versions." This is in response to the rather uninformed and questionable security notice by ISS X-Force, about a bug that has already been mentioned on the public mailing lists for Apache and is fixed in CVS for Apache 2.0. I am also told that their patch doesn't fully solve the problem. I am sure though that by awaking us to the problem they will get a lot of great press just like any of the other companies currently using useless bug announcements as press releases.

cancel ×

307 comments

Sorry! There are no comments related to the filter you selected.

Oh oh (0, Funny)

LinuxCumShot (582742) | more than 12 years ago | (#3717897)

Time to get more eyes on the code.

Important - Need Gook / Geek porn (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3718091)

Does anyone have any pornographic pictures of Mae Ling Mak that I could use for masturbation please?

Re:Important - Need Gook / Geek porn (-1, Offtopic)

Grape Smuggler (569838) | more than 12 years ago | (#3718120)


http://spinster.org/my_photos/

Damn, she is an ugly woman. If you can masturbate to that, more power to ya.

News finally (0)

Anonymous Coward | more than 12 years ago | (#3717899)

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 (4, Funny)

l33t j03 (222209) | more than 12 years ago | (#3717905)

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 (1)

blashyrkh (578000) | more than 12 years ago | (#3718123)

You were being sarcastic, right?

Sarcastic? (0)

Anonymous Coward | more than 12 years ago | (#3718136)

Um... noooooooo.

Enough Already (5, Insightful)

zpengo (99887) | more than 12 years ago | (#3717907)

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 (1)

Anonymous Coward | more than 12 years ago | (#3717922)

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 (2, Informative)

Fantanicity (583135) | more than 12 years ago | (#3717941)

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

Good ... because IIS had a more serious problem with chunking [cert.org]

Spin, spin, spin (1)

The Turd Report (527733) | more than 12 years ago | (#3718134)

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

Re:Enough Already (2)

Telastyn (206146) | more than 12 years ago | (#3717950)

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 (2)

krogoth (134320) | more than 12 years ago | (#3718093)

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 (3, Insightful)

tshak (173364) | more than 12 years ago | (#3717979)

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 (5, Insightful)

homer_ca (144738) | more than 12 years ago | (#3718139)

"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 (3, Insightful)

gilroy (155262) | more than 12 years ago | (#3718143)

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 (2)

SirSlud (67381) | more than 12 years ago | (#3717992)

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.

You new around here? (1, Redundant)

The Turd Report (527733) | more than 12 years ago | (#3718158)

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?

Details of bug (1, Redundant)

fw3 (523647) | more than 12 years ago | (#3718072)

Reportedly advisory [apache.org] 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.

Mod parent down - troll (0)

Anonymous Coward | more than 12 years ago | (#3718096)

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:Enough Already (2)

krogoth (134320) | more than 12 years ago | (#3718108)

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 (1)

ictatha (201773) | more than 12 years ago | (#3718131)

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.

Insightful? (1)

muffel (42979) | more than 12 years ago | (#3718146)

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:Enough Already (2, Offtopic)

SealBeater (143912) | more than 12 years ago | (#3718157)

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 (0)

Anonymous Coward | more than 12 years ago | (#3718197)

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 (1)

zootread (569199) | more than 12 years ago | (#3718164)

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

slashdot.org should be renamed spinroom.org (1, Troll)

sheldon (2322) | more than 12 years ago | (#3718180)

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?

A lot of noise? (1)

rector (580924) | more than 12 years ago | (#3717908)

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

now lets' see... (0, Flamebait)

slayer99 (15543) | more than 12 years ago | (#3717910)

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

First "First Post" Post (-1)

CmdrTaco (troll) (578383) | more than 12 years ago | (#3717913)

nt

Incoming (0, Troll)

tiltowait (306189) | more than 12 years ago | (#3717914)

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

Re:Incoming (4, Insightful)

iCharles (242580) | more than 12 years ago | (#3718040)

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 (0)

Anonymous Coward | more than 12 years ago | (#3718128)

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 (0)

Anonymous Coward | more than 12 years ago | (#3718137)

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

Re:Incoming (2)

gilroy (155262) | more than 12 years ago | (#3718177)

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.

Apache is great! Very useful... (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3717915)

Especially for posting a web site about how much of a fucking ass-nad Brian McFucking Ellenberger [slashdot.org] is. Make sure you tell his stupid fucking holier than thou ass what you think of horn-swallowers like himself..

----
wTf

Not enough time!! (2, Funny)

dpete4552 (310481) | more than 12 years ago | (#3717916)

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.

Arrrgggh my fucking eyes! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3717918)

Im blind from the purple and piss color color scheme found on this page.

A bug in open source code? (2, Funny)

Anonymous Coward | more than 12 years ago | (#3717927)

That's unpossible!

IIS r0x0rs! (-1, Offtopic)

gerf (532474) | more than 12 years ago | (#3717928)

W is for windows

it's good enough for me

W is for windows

it's good enough for me

w is for windows

cause i'm a big dummie!

Useless bug announcements-- My turn! (3, Funny)

rocjoe71 (545053) | more than 12 years ago | (#3717934)

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

Finally... (1)

RAMMS+EIN (578166) | more than 12 years ago | (#3717935)

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 (1)

mackstann (586043) | more than 12 years ago | (#3717937)

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

Here's some holes I'd like to exploit... (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3717942)

GOOOAAALLL [filepile.org] !

(Brazil Women's Soccer Team!!)

It's still better than IIS (2, Insightful)

Anonymous Coward | more than 12 years ago | (#3717949)

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.

Apache team not trusted (5, Interesting)

neoThoth (125081) | more than 12 years ago | (#3717954)

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 [securityfocus.com] 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 (4, Informative)

fatphil (181876) | more than 12 years ago | (#3718008)

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.

It's called "Full Disclosure" (0)

Anonymous Coward | more than 12 years ago | (#3718129)

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 [slashdot.org] , and the Slashdot crowd are usually applauding it when it's applied to Microsoft.

Re:It's called "Full Disclosure" (2, Insightful)

neoThoth (125081) | more than 12 years ago | (#3718167)

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.

Thoughts on this hole (4, Interesting)

ajrez (99515) | more than 12 years ago | (#3717955)

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

Full disclosure and reputations... (4, Interesting)

sterno (16320) | more than 12 years ago | (#3718140)

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.

And AOLserver is still unaffected (0)

Anonymous Coward | more than 12 years ago | (#3717956)

You apache and IIS nancies can kiss my ass.

Who cares?? (0)

Anonymous Coward | more than 12 years ago | (#3717957)

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

Anonymous Coward | more than 12 years ago | (#3717958)

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"? (0)

Anonymous Coward | more than 12 years ago | (#3717961)

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"? (1)

cliffwoolley (506733) | more than 12 years ago | (#3718042)

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

Bugs Apply To All Software (1)

jaxon6 (104115) | more than 12 years ago | (#3717962)

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 (5, Informative)

jukal (523582) | more than 12 years ago | (#3717964)

From the bulletin [apache.org] :
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 (2)

wytcld (179112) | more than 12 years ago | (#3718017)

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 (2, Informative)

Evro (18923) | more than 12 years ago | (#3718045)

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 (2)

jukal (523582) | more than 12 years ago | (#3718082)

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

You shouldn't run Apache as Nobody (2, Informative)

Anonymous Coward | more than 12 years ago | (#3718161)

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

Fix for 1.3.x tree? (0)

Anonymous Coward | more than 12 years ago | (#3717968)

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? (2, Informative)

cliffwoolley (506733) | more than 12 years ago | (#3718024)

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? (3, Informative)

jukal (523582) | more than 12 years ago | (#3718050)

> 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? (2, Informative)

caluml (551744) | more than 12 years ago | (#3718092)

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

AnotherSteve (447030) | more than 12 years ago | (#3718145)

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

ISS patch is not complete (5, Interesting)

btellier (126120) | more than 12 years ago | (#3717969)

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.

-----

Double standard (2, Insightful)

bluegreenone (526698) | more than 12 years ago | (#3717970)

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 (3, Insightful)

Builder (103701) | more than 12 years ago | (#3718080)

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.

Yeah, McAfee fucking sucks, Slashdot is right! (-1, Flamebait)

Bowie J. Poag (16898) | more than 12 years ago | (#3717978)



Yeah, McAfee sucks. They protect tens of thousands of people's data against viruses, for free. Yeah, they're completely useless, and should be kicked off the face of the earth.

Oh wait, I have a better idea -- How about Slashdot gets a clue, instead?

Cheers,

stop yer whinin' fool. (0)

Anonymous Coward | more than 12 years ago | (#3717983)

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?

It's not just a DoS (2)

btellier (126120) | more than 12 years ago | (#3717985)

This is a memory mismanagement issue, AKA a sort of buffer overflow. In this case, under certian platforms and implementations it can be exploited to execute arbitrary code with the web server's UID (usually nobody/www/nopriv/etc). It's worse than you think.

Serves you right... (0)

Ramuh (153125) | more than 12 years ago | (#3717986)

...for using a patchy [computergear.com] web server

ugh...

This is Good News for Linux (0, Troll)

Jeff Probst (459812) | more than 12 years ago | (#3717990)

Once again, open source software (OSS) has come up looking better than commercial software from Micro$oft. While it takes M$ several days to close IIS security holes[1], Apache is right there with a fix upon announcement.

Executives at Fortune 500 companies will see that apache and linux, while inherently insecure, make up for it by posting fixes a few days after the initial reports, and switch to apache and linux.

The window of opportunity for exploiting a security hole quite narrow in the scheme of things[2].

[1]. See slashdot.org
[2]. There are 365 in a year, a day is neither here nor there.

Re:This is Good News for Linux (0)

Anonymous Coward | more than 12 years ago | (#3718047)

Ya except for all the millions of people still running apache 1.3.x, you know, like anyone who might use this wacky php thang...

don't toot your horn so fast mmmkay...

As it says there is an expiramental patch in CVS for the 2.0.x branch that may or may not fully fix the problem.

Also the slashdot editor brangs that "oh the apache team already knoew about this for weeks"...so do actually bother to tell anyone? what they hoped no one would notice that little doozy eh?

Re:This is Good News for Linux (1)

nickgrieve (87668) | more than 12 years ago | (#3718118)

What about Apache on the Windows platform, best of both worlds. leading industry technology in your Operating system and a open source http server.

doesnt it saw "windows version"? (1)

prmths (325452) | more than 12 years ago | (#3717994)

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"? (1)

prmths (325452) | more than 12 years ago | (#3718025)

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

Re:doesnt it saw "windows version"? (1)

cliffwoolley (506733) | more than 12 years ago | (#3718068)

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

Oh lovely (1)

sheepab (461960) | more than 12 years ago | (#3717998)

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

Anonymous Coward | more than 12 years ago | (#3718001)

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

I just kept walking.

Penguin? (0)

Anonymous Coward | more than 12 years ago | (#3718113)

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

Re:I work at MS... (0)

Anonymous Coward | more than 12 years ago | (#3718156)

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

I always like how (0, Flamebait)

JeanBaptiste (537955) | more than 12 years ago | (#3718013)

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!!!! (0)

Anonymous Coward | more than 12 years ago | (#3718023)

YOU'RE NOT SUPPOSED TO TELL ANYONE!!!

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

-- Bill

Let the spinning begin! (-1, Troll)

The Turd Report (527733) | more than 12 years ago | (#3718030)

Ok Slashbots. Start spinning this to show how OSS is awesome cause a bug was found. When it is a MS bug, it is the worst bug to ever exist, but when it is an OSS product, it is a trivial issue.

Re:Let the spinning begin! (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3718100)

It's interesting how Slashdot's editorial slant changes when the security news sites aren't posting about a Windows server bug, isn't it?

All of a sudden, the gloating disappears, and the spin-control begins. It's almost like Slashdot is owned by a open source consulting company... Oh, wait, IT IS. Sorry, never mind.

Re:Let the spinning begin! (2)

jonabbey (2498) | more than 12 years ago | (#3718148)

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.

Ridiculous!!!! (0)

Anonymous Coward | more than 12 years ago | (#3718032)

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

right?

A complaint! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3718053)

norrog@linux:~> cat complaint.troll
The ADS on $la$hdot and the O$DN ANNOY ME.

Ones that annoyme most,
$hit forge adverts, no one want's to risk developing critcal applications
with you so fuck off!

AnimeFu/Megatokyo adverts! Japanime sucks, so does slashdot!

Microsoft Visual Studio .net adverts! Why the FUCK are you letting the
devil advertise with you. Oh now I remember, open sores have no way to
make money so they ask big companies to support them!

Conclusion. Don't tolerate it! Don't subscribe to $la$hdot. Instead go
and install Junk buster [junkbuster.com] and say no to shitty adverts! The
ones found here are worser than the pr0n sites!

What happened to disclosure lead times? (5, Interesting)

Builder (103701) | more than 12 years ago | (#3718061)

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!

Pot, Kettle, Black (0)

Anonymous Coward | more than 12 years ago | (#3718078)

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?

Mississippi Ghostse (-1)

GhostseTroll (582659) | more than 12 years ago | (#3718086)

A professor at the University of Mississippi is giving a
lecture on the supernatural. To get a feel for his
audience, he asks: "How many people here believe in
ghostses?" About 90 students raise their hands.

"Well, that's a good start. Out of those of you who
believe in ghostses, do any of you think you've ever seen
a ghostse?" About 40 students raise their hands.

"That's really good. Has anyone here ever talked to a
ghostse?" 15 students raise their hands.

"That's great. Has anyone here ever touched a ghostse?" 3
students raise their hands.

"That's fantastic. But let me ask you one question
further... Have any of you ever made love to a ghostse?"
One student way in the back raises his hand.

The professor is astonished and says, "Son, all the
years I've been giving this lecture, no one has ever
claimed to have slept with a ghostse. You've got to come
up here and tell us about your experience."

The redneck student replies with a nod and a grin, and
begins to make his way up to the podium. The professor
says, "Well, tell us what it's like to have sex with
ghostse."

The student replies, "Ghostse?!? From ah-way back there ah
thought yuh said "goatse." [goatse.cx]

Scuse me (1)

Second_Derivative (257815) | more than 12 years ago | (#3718090)

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?

Most can wait for a patch (2)

Lxy (80823) | more than 12 years ago | (#3718141)

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 (1)

Builder (103701) | more than 12 years ago | (#3718191)

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.

Don't point the finger at ISS. (1, Troll)

dave-fu (86011) | more than 12 years ago | (#3718162)

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.

don't believe the FUD (-1, Troll)

tps12 (105590) | more than 12 years ago | (#3718181)

While I'm sure all the Windblowze supporters are crowing about this, I want to make a few points just to put it in perspective.

First of all, this is the first vulnerability in a long time for Apache; contrast that with the number of holes found in IIS just about every time you turn around. Second, notice how quickly it was found and corrected. That's another thing you won't get from Microsoft. Finally, compare the seriousness of the exploit with the crippling effects of having an MS server attacked.

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.

Too good (3, Funny)

selectspec (74651) | more than 12 years ago | (#3718188)

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?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?