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