Slashdot Mirror
Apache 2.0 r00ted on NetWare, Windows, OS/2
An anonymous reader writes "A flaw in Apache 2.0's interpretation of the backslash delimiter allows for a remote r00ting on NetWare, Windows, and OS/2. InfoWorld has an overview; the attack was discoverd by PivX's Auriemma Luigi, and he describes it in this technical document. I don't know whether there is such a thing as an OS/2 shop anymore, and most Microsoft shops probably run IIS, but Apache now ships as the default web server for NetWare 6, so Novell shops: Take note. A patch is available from Apache, and Luigi describes a workaround in his article."
Apache 2.0.40 was released August 9th, fixing the hole. You can read the advisory, but you should have upgraded already. The real news is that many Apache web servers are still unpatched. Won't admin's ever learn?
NetWare is an operating system and has nothing to do with Windows at all. Last time I used it, it did still require you to boot into MSDOS first, but once you ran its EXE, it kicked DOS out and completely took over. It used to be the most popular network operating system, but NT has pretty much killed it. It's still around though....
While I'm sure this will look like anti-MS propoganda, there are certain points to be made here. I have strong negative feelings about the quality of MS's security approach in (1) minimizing local break-in damage, (2) keeping software from having holes, (3) keeping software from being attacked, and (4) vendor bug response approach.
MINIMIZING BREAK-IN DAMAGE
Yes
Yes, services on Windows *can* run as all different users, a la UNIX -- I have ftp, pdnsd, apache, junkbust, squid, xfs, postfix, and sshd set up on my Linux box by default. However, in Windows, *usually*, and *by default* they don't.
Dunno whether Apache for Windows is set up as its own user by default, but most services for Windows don't take advantage of this. You could say that this isn't MS's fault, that there's just less of a multi-user culture around Windows than UNIX, but the fact is that Windows boxes are generally more vulnerable to full compromise in a break-in.
Second, Windows has no concept of "chroot". If I lock something in a chroot jail on UNIX, a hole in a server means next to nothing to me. You broke the server? The files served by the server had better be valuable in and of themself, since you can't get at or see anything else. This doesn't affect most out-of-box distros, since most distros don't go to the trouble of using chroot -- but sites that really value security do use chroot. On Windows, there is no such available option.
Basically, UNIX has a better ability to sandbox, and its capabilities are much more widely used than on Windows -- your average server software developer takes advantage of them on UNIX -- but not on Windows.
KEEPING APPLICATIONS FROM BEING BUGGY
This is a Windows-specific pathname issue. There have been more Windows-specific pathname exploits in Windows servers than I can count. The MS approach of having an extremely convoluted pathname system (particularly files having non-unique names with the backwards compatible 8.3 support) has led to many, many issues with servers. IIS has had numerous holes involving this, and it seems like just about every Windows FTP or Web server has suffered from this at one point or another.
Next, people often complain that UNIX doesn't have ACLs, whereas Windows does. ACLs seem really attractive -- a very easy way to do security work. The problem is that they are much more complicated, and orders of magnitude harder to audit for holes, than the minimalist UNIX security model. Most break-ins are not due to someone literally not having fine-grained enough security -- they're almost always the fault of misconfiguration, which a simpler security model makes massive improvements in. If anyone's every admined a VMS box, you know what I'm talking about -- trying to assure that your box has *no* routes for someone to gain control of the box can be interesting, despite VMS's very fine-grained security model.
Out of box Windows file and registry permissions still hurt the security of Windows boxes -- they aren't as insanely bad as in NT 4.0 out of box any more, but most application vendors are still living in a 9x world, and are focused on adding features, not on maintaining the security model.
Too many Windows subsystems break the Windows security model. I wouldn't trust DirectX and all the non-core stuff on Windows not to have holes -- any yet they post a threat to local security.
As mentioned a while ago in the "shatter attack" article on Slashdot, the windowing model for Windows that worked so well for writing GUI applications easily (well, easily compared to raw Xlib, though Lord knows gtk knocks Win32 into a cocked hat) isn't a very good system from a security standpoint.
KEEPING BUGGY APPLICATIONS FROM BEING ATTACKED
Linux has powerful (granted, not very easy to use, at least without a wrapper) firewalling/routing capabilities through iptables. If your box is ignoring everying from port 22 from outside the computers on your three-person-team at your company, it's rather harder to exploit, say, SSH buffer overflows, or even find a vulnerable server.
Windows has Zone Alarm (and probably other local firewalls, but this is definitely the popular one). Now, this is probably nice for a workstation, but it doesn't compare with iptables in performance, and it doesn't provide the level of control that iptables does. If my internal web server running Apache isn't exposed to people not in my workgroup, then there isn't going to be much exploitation of the server.
MS BUG RESPONSE APPROACH
It's not really all that fair to compare the "46 minute" response time of open-source developers to MS's response time. Yes, in extreme situations someone could get the patch and apply it, in cases of something like the Internet Worm II. Most companies are going to wait for their vendor, be it Red Hat or SuSE or whatever, to come out with a packaged, QAed and supported update. That being said, these fixes still usually come out before MS's fixes. Furthermore, MS eliminates a bunch of their quality guarantees that they provide on Service Packs when you're using HotFixes. Red Hat (at least -- I haven't checked with other vendors) doesn't do that. Their bugfixes are just as fully supported, just as guaranteed to roll back, as their release software. That means that their updates better compare to Service Packs, which take forever and a day to come out after an exploit. So MS usually takes a long time to fix bugs.
Also, MS's primary to-end-user bugfix distribution format is Windows Update. Windows Update is one of the least impressive update systems I've seen yet -- it's used to update system software, yet it relies on a huge amount of application and system software. If it screws up, you're dead. And I've had a number of unpleasant experiences with Windows Update failing one way or another -- for example, once I had a bluescreen on a reboot after updating and trying to run MSIE (keep in mind that this is an NT-line kernel, not 9x). I've seen error dialogs during updates, and other semi-disturbing blemishes. After two incidents where Windows Update rendered boxes unbootable, I've taken to not running Windows Update (even to fix security issues) unless I have a known free two days to reinstall the OS and get everything running wrinkle-free again if something goes hideously wrong.
Furthermore, because of the way Windows does file and DLL locking (stupid, stupid -- ever try moving/deleting/renaming an open file under Windows? Combined with Explorer sometimes leaking file handles, this is a royal PITA), low-level updates usually require a reboot. The only Linux update that requires a reboot is a kernel update (though updating a desktop environment or a WM requires logging out and back in again to see the changes). Finally, I've ripped out much of my RPM-based Linux system and put in back in (bits of different distros, bits of devel-branch software) and always had smooth moves, nothing that could make my system unbootable. I feel a lot more confident in an RPM installation or uninstallation than I do in a Windows update.
Anyway, just my two cents -- just wanted to point out that this issue can still be partly blamed on Windows security issues, and not wanting people to lose sight of the areas in which MS needs to improve.
May we never see th