Slashdot Mirror
Serious CGI Bug in MacOS X Servers
menthos writes "Multiple CGI queries appearently causes the MacOS X server kernel to do a "System Panic", making MacOS X almost useless as a web server. The
German computer magazine c't has
the story (in english)
"
First, so far many people running OS X Server have had difficulty getting this script to work. It also does not affect all CGI queries....just this ApacheBench thing specifically. If you disable the ability of someone to run ApacheBench, it wouldn't affect it at all. Apparently a lot of it has to do with what daemons are running, which is why so many people have failed to recreate this problem.
It just isn't quite accurate for you to say that all multiple CGI queries can crash OS X Server, because that isn't the case.
Do you read any other tech news site? Every single one has an OS that they tend to favor... Whether it be MacOS, or BSD, or Windows, or Linux. complaining about it doesn't do anybody any good. If you don't like the stories posted, then you have three option.
That way, everyone gets is happy. The people who like the site don't have to sift through garbage in order to read the real comments.
This got alot of coverage yesterday on the Macintosh sites.
MacOsRumors talked about it and I am going to quote them.
"1. This problem has so far been only reproduced when the 32+ CGI processes are spawned by a benchmarking CGI -- this problem may or may not actually affect other types of CGIs. It is very possible that it does not. Thus, the problem can be avoided simply by removing the Apache Benchmark CGI from the cgi-bin directory or setting its permissions to prevent it from running ("chmod 500 filename.cgi" should be sufficient).
2. The problem is not fundamental to OS X, according to Apple sources. Although the specific issue has not yet been determined, it appears to be related to Apache's use of system resources (although the issue itself is apparently in the kernel) and is not likely to affect OS X under any other conditions. A patch is in development and should be available very soon."
Since when does a bug make something "worthless", oh when it's made by Apple.
Am I the only one who remembers the glory days before Microsoft when a 1.0 release was ready to go?
You must have dreamed that. A 1.0 (or even x.0) release of any software is never quite ready to go, not even in the realm of Open-Source.
Why? Because before 1.0 is released, the program is tested. Testing methods can be pretty thorough, but you can never test every possible situation, no matter how hard you try. Even in Open-Source projects, no one can get them all. Someone is guaranteed to put that software into some scenario you didn't think about, and might or might not run into a bug there. It's the proverbial million monkeys banging on a million typewriters; eventually one of them will type out Hamlet (OK, so maybe comparing a computer glitch to a Shakespeare play isn't an appropriate metaphor, but you know what I mean).
To be honest, I'm rather surprised that it took this long to find a major bug in OSX. Even Linux bugs seem to be found much more quickly than that. I find that fact to be something of a testament to Apple's quality control. Yes, bugs were found; bugs are inevitable (even Linux and *BSD have them). But it certainly took a long time to find one. And the one they did find can't seem to be reproduced in any reliable way; people have tried and only one or two seem to be having the problem.
No one is using it? There are two flaws in your argument:
1) It's only been out for a couple of months. That's hardly a point when someone can even really begin to say that. "No one" used Linux for the first couple of months after its release either. Give it a break.
2) It's growing. Rather quickly, actually.
Have source, will fix, no problem! Bug reports are a Good Thing! It ensures quality control.
Let me start by saying that I enjoy reading /. articles and usually the discussions that follow. There are generally enough intelligent, informative, open-minded posts to make it worth my time to read them.
/., it is just an opportunity for the same old arguments to get rehashed. For example, in this case, there are a handful of useful posts concerning the OS X story. The rest are the SAME old trolls and useless arguments that I have seen any time I look through posts re: a Mac related story, many not related to the current story at all!!!
I should also mention that I work on Macs, PCs, Unix and Linux. These are tools, each has strengths, and I am not an evangelist for any particular platform,
However, it seems that any time a story to Macs appears on
Moderation helps a little, but it is too bad I can't filter the posts by some more specific criteria. In this case, I'd be interested in seeing:
- who has tested this phenomenon on an OSX box
- recent information about this bug
- information about this (or similar) phenomena on OTHER Apache servers
Am I in the minority here to be interested in the technical issues here? Are there really that many people who would rather bicker about the Mac GUI vs other GUIs or whether a one-button mouse is inherently inferior to a multi-button mouse? I am sure that I will be flamed as a result of this message, but I am frustrated (and disappointed) by the petty squabbling that is going on, and curious if anyone else out there feels the same way.
YS
"Arrr! The laws of science be a harsh mistress." -- Bender
Other Mac sites have reported this bug last night, and it seems that some are unable to reproduce the bug. The conclusion seems to be that it depends on the configuration.
Also, Apple reported that it was working on a patch since yesterday.
Heres an update from MacOSRumors:
UPDATE: Thus far, ten readers have written in with reports -- so far, only one has been able to duplicate this problem using C'Ts script...and at Black Light, with our testbed OS X Server machine, the script did not cause any errors. Discussing the problem with Apple turned up the fact that depending on configuration, some (possibly many) OS X Server installs appear to be proof against the problem. One suggestion from Cupertino is to disable as many other service daemons as possible on your server to maximize your chances -- and, of course, this also improves memory usage and overall performance.
End quote. Thus far it isn't a 100% reproducible bug. That being the case, anyone know how Apple knows what/how to fix it? Regardless, lets see how fast Apple can fix this...
-AS
-AS
*Pikachu*
If the story had been "CGI crashes Linux", would you have reacted the same way?
There seems to be a lot of confusion surrounding this issue, and I've put a explanation up at macnn.com, but it makes sense to try to help as many people possible understand exactly what the problem is -- including Apple. :) Here is the crash case:
/Local/Library/WebServer/CGI-Executables/. By default, the script is not executable. You must 'chmod +x test-cgi' for it to work. However, this could probably happen with any script, though tests of that sort were not published.
/Local/Library/WebServer/CGI-Executables
When 32 or more copies of ApacheBench (ab) are pointed at a CGI script on a website running on Apache/Mac OS X Server machine, the kernel will panic, usually within 30-60 seconds, forcing a reboot.
The general thinking is that this many copies of ApacheBench running at once mimicks the load generated by hundreds of clients accessing a site at once. ApacheBench can be launched locally or remotely (assuming sufficient bandwidth), which is where the problem comes in. Somebody with malicious intent could decide to launch 32 copies of ApacheBench _from_their_machine, against a server, and crash it.
In the test, c't directed 32 copies of ApacheBench at the "test-cgi" script which is in
I actually tested this on my Blue G3/400 running MOSXS and did get a kernel panic. I got essentially the same results whether launching the attack from the same machine that the webserver itself is on, or launching the attack from a linux machine on the same network. Incidentally, I ran this same test again a Red Hat Linux 5.1 (2.0.34 kernel) box, which did not experience any problems during the "attack."
Important Points:
----------------
(1) This is, first and foremost, a security concern. The type and volume of traffic required to make the OS crash would most likely not be generated by normal web clients. However, ApacheBench can be launched remotely, and with malicious intent.
(2) The crash is not triggered by 32 successive CGI requests, as some people seem to think. Informal MacNN tests show that in one case, Apache actually serviced 1666 CGI requests in 26 seconds before crashing. The c't article is a bit confusing in this manner, but the "32" refers to 32 or more ApacheBench processes being launched -- each of which issues hundreds of requests.
(3) The problem is not with a particular CGI script. It is a problem with an immense ammounts of requests for CGI scripts coming in during a very short period of time.
(4) The problem can not be stopped by simply removing ApacheBench from the server. An attack can be launched remotely.
(5) The script used for the c't test is a bourne shell script. A Perl or C script may not exihibit the same results. PHP may also be immune (though I have no proof of any of that).
(6) This problem is most likely present in Darwin as well, so those interest in resolving the problem could probably download the source and work on a fix.
(7) Red Hat Linux 5.1 (2.0.34 kernel) running Apache 1.3.3 seems to weather the attack well, so it's almost certainly an OS issue.
(8) In some cases, bandwidth may become constrained before an attack is successful in bringing down the system.
Possible workarounds:
--------------------
(1) Configure router to filter immense number of requests from one IP address (like DoS attack)
(2) Disable CGI execution, or simply remove all files from
(3) Disable Apache, if you're only using MOSXS for Macintosh management, AppleShare or QuickTime streaming
Scott Stevenson
Macintosh News Network
http://macnn.com/
Scott Stevenson
Tree House Ideas
Additonally, I remember recent QuickTime 4.0b bashing. Many of the comments should have been moderated-out as they were nothing more than flames. However, many of the comments should have been forwarded directly to Apple so they could actually fix the bug!
Does anyone remember back to the days of Windows 1.0? It wasn't even usable. How about the early releases of Linux? More usable than Windows 1.0, but hardly enterprise worthy.
MacOS X Server 1.0 is just that---a 1.0 release. It's going to have a few bugs, most minor and a few major. If you don't like it, don't use it. Better yet, fix it yourself. It's OpenSource, after all.
----
Am I the only one who thinks Microsoft is a misnomer? Perhaps Macrosoft would be a better fit?