Slashdot Mirror
Apache Vulnerability Announced
Aaron writes "Versions of the Apache HTTP Server up to and including 1.3.24 and 2.0 up to and including 2.0.36 contain a bug in the routines which deal with invalid requests which are encoded using chunked encoding. In some cases it may be possible to
cause a child process to terminate and restart,
which consumes a non-trivial amount of resources. See the official
announcement and stay tuned here for updated versions." This is in response to the rather uninformed and questionable security notice by ISS X-Force, about a bug that has already been mentioned on the public mailing lists for Apache and is fixed in CVS for Apache 2.0.
I am also told that their patch doesn't fully solve the problem. I am sure though that by awaking us to the problem they will get a lot of great press just like any of the other companies currently using useless bug announcements as press releases.
Proof positive that IIS is a better web server than Apache. You don't see IIS vulnerabilites spouted all over the internet every day.
Cunning linguists
...oh, wait.
You mean *nix admins actually have to worry about patches and service packs too?
Don't get me wrong, I don't intend this to be an "I told you so!" from the MS camp to the *nix camp, but rather a polite reminder that all admins have to keep up with their patches, service packs, and whatever. You can't just install Apache and let it go. You need to know what you're doing.
There's a difference between an "admin" and "someone who installed some software".
Got Rhinos?
"Useless bug announcements" are a special topic. May be, some bugs appear intentionally to make a lot of noise of it?
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.
http://www.archive.org/details/ThePowerOfNightmares
That's unpossible!
The Rocjoe Institute is reporting that under some conditions, Windows *may* crash...
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
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
Please correct me if I got my facts wrong.
so how long before i need to apt-get update && apt-get upgrade? :)
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.
I posted this as a story earlier...
Turns out the ISS X-Force team doesn't trust the Apache crew to fix what seems to be a very serious exploitable bug in the http code. They just released an advisory to the Bugtraq mailing list here and provided some 'patch code'. The patch code (which attempted to typcast the vulnerable area) doesn't seem to fix the issue.
So in effect there are a bunch of Apache servers out there with a possibly remote exploitable buffer overflow. Was this a big ooops on the part of ISS?
One has to wonder why they didn't go to the Apache team first with this? Rumor has it that ISS feels that Red Hat has burned them (ISS) in the past and since the Apache team has some Red Hat employees they shouldn't be trusted.
Another rumor that has been floating is that the ISS team doesn't consider Apache to be "a vendor" and therefore doesn't need to follow the normal disclosure rules. This sets a pretty bad precedant of not working with vendors just because you don't get along with them. A companies personal pettiness should not be allowed to override the security of a majority of the internets websites. The patch has offically made it into the Apache CVS but again why the hell didn't ISS talk with Apache? I noticed another post by NGGS (referenced in link above) that they already had a CVS number so they appeared to have gone through the proper channels and got 'beat to the punch' by ISS. Sounds like a motive to me....
(A) Bugtraq and associated lists perhaps have held off on posting this, MAYBE, but then this brings us back to the Full Disclosure arguement.
(B) Better question: Why is ISS releasing a poorly researched hole (they didn't even know that Apache 2.x had it) and a worthless patch prior to contacting the vendor? Premature ejaculation here or WHAT?
I fail to see what their hurry was, lest their market share is dipping and they really needed to beat someone (such as David Litchfield?) to the punch.
This is completely irresponsible. There are scores of devices that use Apache embedded. These manufacturers and THEIR clients now need to come up with something *fast* to get locked down.
F'n genius....
I have become, comfortably numb
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.
Do you see the sig? Do you have it in your sights? Why yes, Miss Moneypenny...
From the bulletin:
Due to the nature of the overflow on 32-bit Unix platforms this will cause a segmentation violation and the child will terminate. However on 64-bit platforms the overflow can be controlled and so for platforms that store return addresses on the stack it is likely that it is further exploitable. This could allow arbitrary code to be run on the server as the user the Apache children are set to run as.
It seems that thanks to the *nix way of handling processes and their childs, this represents minor threat than on other platforms, in which it is even more easily exploitable as a DOS attack. However, this is not minor news eve for us using *nix breeds.
As noted by valcu.gheorghe@caatoosee.ro on Bugtraq:
:
----
The patch that mentioned casting bufsiz from an int to an unsigned int
failed to do a few things:
1) There are 2 instances of the same code in http_protocol.c that need
to be fixed, as both suffer from the same problem
2) The cast to unsigned int was only done in comparison, and was not
done in assignment, which could possibly lead to problems down the road
with the int value?
I haven't checked any of this, just noticed it and was really just
wondering "why wasn't this done?".
The code that is apparently "buggy" is this:
len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
The code was mentioned to be changed to this:
len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz
r->remaining;
However, this doesn't assign that casted value to len_to_read, it just
uses the cast for comparison and then passes on the possibly bogus data
on to len_to_read.
So, should the fix not be to change it to:
len_to_read = (r->remaining > (unsigned int)bufsiz) ? (unsigned
int)bufsiz : r->remaining;
Also, like I mentioned, there are two places where this happens in
http_protocol.c, one at line 2062, and the other (the one mentioned in
the patch) at 2174.
-----
So your company publicizes a bug for IIS, you're a hero. Publicize one for Apache, you're now "uninformed and questionable"? Geez.
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?)
p r m t h s
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!
In college, really poor, need a flatscreen.
Updated releases of both 1.3 and 2.0 that fix this problem will be released VERY shortly.
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.
The fact that it doesn't describe the entire scope of the problem. See the official announcement on httpd.apache.org to understand why.
> PHP doesn't work on 2.0 yet, so upgrading to 2.0 is not an option for us. Now what?
Meanwhile, if you HAVE to use Apache 2.0, run PHP as CGI and you will avoid the version hassle (ofcourse loosing on performance etc). Anyway, it won't take long now to have PHP4 working good as module with 2.x, as the big guys are saying that the Apache API is now kind of stabile for 2.x series.
WTF!?!?!
What happened to the lead time given to a software vendor before publishing a vulnerability ? I thought that all professional 'sploit hunters honoured this.
The idea is to give the vendor time to produce a patch so that when you announce the vulnerability there is an official patch available. It's 22:16 here now and I'll be sat up half the night waiting to see if Apache release a patch because I have around 20 servers that run Apache, and I can't sleep until I know they're secure.
I'm all for full disclosure, but I much prefer RESPONSIBLE full disclosure. If anyone from IIS is reading this, you're a bunch of immature mornons. Play by the rules or fuck off!
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.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
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?
I am running Apache 2.0.36 and PHP 4.1.2 at the moment. It's stable enough, and quite easy to install. .php thing in the conf file too. Search on Google if I'm none too specific ;)
Install Apache from source, then configure PHP with --with-apxs2=/path/to/apache2/bin/apxs and install.
Do the x-httpd-application
Get your own free personal location tracker
Jesus, I am getting dizzy with all the spinning you OSS guys are doing.
Michael Loves Me!
Well, I think it can be safely reasoned that ISS cannot be considered a reputable security organization. Do you really want to give these guys any money when:
1) They are unable to fully understand the nature of a discovered flaw
2) They are unable to release a patch that solves the problem (demonstrating a lack of a good QA process)
3) They have demonstrated an inability to work effectively with industry leading software developers
I don't know about you, but I'd be hard pressed to trust my business or even my home data to the security of an organization that is so apparently incompetent. They have a lot of 'splaining to do.
This sig has been temporarily disconnected or is no longer in service
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.
There is no reasonable defense against an idiot with an agenda
:wq
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.
Information wants to be $1.98/lb.
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?
bla
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.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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?
Michael Loves Me!
Oh no! User nobody is wreaking havoc!
/tmp (if it needs a temp folder, it gets it's own.)
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
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.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
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.
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.
The Mongrel Dogs Who Teach
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?
Please note that the patch provided by ISS does not correct this vulnerability.
Will upgrading to 32-bit color on my hard drive fix it or do I need to upgrade my monitor refresh rate to 512MB?
Someone you trust is one of us.
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.
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 to this story can also be found here
Ace
It hasn't been corrected yet. Many sysadmins in Europe will be sitting up tonight waiting for a patch.
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.
-- Mark Cox, http://www.awe.com/mark/
The post above is the only intelligent post for discussion on this issue so far.
you're a bunch of immature mornons ;)
the middle 'n' should be an 'm'. No harm done, however,
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.
But this is not the issue here, the issue here is security and common sence. Why would a sercurity team(with common sence =):
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.
Question: where do I change the default "chunk encoding" response to an invalid request?
-- @rjamestaylor on Ello
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
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.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
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.
>> Many sysadmins in Europe will be sitting up tonight waiting for a patch.
:o)
Not me - I'm off to sleep now
If anyone works out how to exploit it before the latest rpms and debs filter on through, I'll be damned suprised.
Get your own free personal location tracker
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
----
I found this message and this message (from bugtraq) to be informative regarding the interesting issues here.
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?
All spelling in context, all emphasis is quasi steller's:
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.
Digital Citizen
The fact is, I do trust the Apache group. And for good reason. I know the code is flawed because I write software for a living. All code is flawed, and to believe otherwise is folly. I also know that the competing products are also flawed. What Apache offers that none of their major competitors provide is access to the code. Give me the patch, and I'll apply it myself. If I'm still concerned, I can have a look around the code. And most importantly, they do a much better job at getting the fixes out in a timely manner.
Unfortunately, the exploit clock is now actively running which, no thanks to ISS, was an otherwise unnecessary hassle. That said however, I am confident that hundreds of very concerned and capable open source programmers will be able to outpace the dozen or so overworked and underpaid software engineers who have the misfortune of handling Microsoft's IIS holes.
Lastly, the vendors who provide Apache in their distributions do not have a monopoly on the market place. Their response time is critical to their relationship with their customers. Microsoft, by comparison, has no such relationship with their customers. Having personally been on the receiving end of many thousands of hours of Microsoft's service contracts, partnership deals, inside promotions, and developer support, I can safely say that we spent a lot of money for nothing. Microsoft ignores their preferred partners and Fortune 500 customers just as much as they discount the average desktop user. Through various positions, I've participated directly in all three cases, and after years of poor support from Microsoft, Linux has become a necessary and major factor in how I do business.
-Hope
Versions of the Apache web server up to and including 1.3.24 and 2.0 up to and including 2.0.36 contain a bug in the routines which deal with invalid requests which are encoded using chunked encoding. This bug can be triggered remotely by sending a carefully crafted invalid request. This functionality is enabled by default.
In most cases the outcome of the invalid request is that the child process dealing with the request will terminate. At the least, this could help a remote attacker launch a denial of service attack as the parent process will eventually have to replace the terminated child process and starting new children uses non-trivial amounts of resources.
We were also notified today by ISS that they had published the same issue which has forced the early release of this advisory. Please note that the patch provided by ISS does not correct this vulnerability.
The Apache Software Foundation are currently working on new releases that fix this issue; please stay tuned here at http://httpd.apache.org/ for updated versions as they become available.
[Link to full advisory follows at http://httpd.apache.org/info/security_bulletin_200 20617.txt ]
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?
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..."
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."
Aw, fuck it. Let's go bowling. - The Big Lebowski
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
--- Why are you wearing that stupid bunny suit? | Why are you wearing that stupid man suit?
Are you trying to say that Apache HTTPD is not widely used? (Sorry, if I have not understood you)
root@aio:~# nmap -sX -iR -p1- # Ho, ho, ho! Merry Xmas, everyone!
would be if Slashdot was hacked and this is the story that the hackers came up with :)
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
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.
IIS remote code exploits every day, and in all this time all we ever see for apache is a potential Deinal of Service.
:)
Nice
autopr0n is like, down and stuff.
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.
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.
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)
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
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.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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.
Comment removed based on user account deletion
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/
Maybe the patches are beta, but I rarely see a string of patches to patches.
May we never see th
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.
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).
Karma? What's that again?
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
return 0;
}
Apache has revised there posting to say that the ISS patch acctually does work.
what happens when I click "User #558038 Info"?
I see a little blurb about "Linus Turdballs" creating the Linux kernel.
return 0;
}
Microsoft's Technet IIS Announcements
Security Updates on Microsoft's Site
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.
Build something beautiful!
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.
Build something beautiful!