MacOS X Circumvents Apache Security

cloudscout writes: "This Report at SecurityFocus.com warns of a problem with the Apache webserver running under Apple's new MacOS X operating system with the case-insensitive HFS+ filesystem. HFS+ is the default (and recommended) filesystem for MacOS X, yet its case-insensitive nature circumvents directory-based security in the Apache webserver that comes with the operating system. The Server version of MacOS X ships with a module that fixes this problem, but this module isn't available unless you purchase MacOS X Server. So much for Apple's boast about 'giving back to the open-source community.'"
From looking through SecurityFocus, this doesn't appear to be the only problem.

Comments

the patch has been posted for over a week

[Anonymous Coward]

download the patch, it's been there since last Tuesday... http://www.opensource.apple.com/projects/darwin/da rwinserver

mod_hfs_apple and Other Mac OS X Server Components

[Anonymous Coward]

Looks like the Server components just weren't posted yet, but they are now: http://www.opensource.apple.com/projects/darwin/da rwinserver/. This should fix the problem.

Re:Saw this coming

[blech]

Macintouch reported today (2001-06-15) that Apple's mod_hfs_apple.c which fixes the problem is available as part of the Darwin Server source code, but also notes that it has not been tested on any 'client' version of Mac OS X.

Easily patched

[CoolVibe]

Some strategically placed tolower() calls in the source would fix this I think. My guess is that the module from apple basically does this too. I got a Darwin/OSX box at home. I will take a gander amd make a patch if I have the time. Shouldn't be a biggie

Hey, you got the source, fix it. You don't even need apple's module. Maybe a #ifdef DARWIN macro for this would be an idea.
--
Slashdot didn't accept your submission? hackerheaven.org will!

Re:So how does Apache cope on Windows?

[Coward, Anonymous]

So how does Apache handle the Windows (NT or whatever) filesystem. Last time I looked that was case-insensitive too

Apache uses ap_os_canonical_filename() which on case sensitive unices is a macro to replace it with the filename, but the util_win32.c provides an ap_os_canonical_filename function which converts the name to lowercase thus allowing "This" and "ThiS" to match (both being returned as "this"), so something similar is needed on case-insensitive MacOS machines.

Re:Saw this coming

[mr100percent]

Did you honestly think Apple is going to release portions of their code, that they paid good money to programmers to write, that isn't GPLed?

Re:So how does Apache cope on Windows?

[babbage]

Yeah, I've been wondering about that one too. I'd never heard it discussed before this, but it does seem like it would be a hole to be fixed on any case-insensitive filesystem, including both Windows FAT32 and NTFS, in addition to Mac HFS.

I was thinking mod_speling might be a ready solution to this issue, but it might not work in the way I was hoping. This bug seems to come up during the parsing of access control settings (early in the request phase), whereas I think mod_speling comes in later, during the mapping of URLs to permitted filesystem points. I think. Nonetheless, even if it can't fix the problem out of the box, I think mod_speling could perhaps be adapted to this purpose if someone knew what they were doing. I'd take a shot myself, but my understanding of Apache's architecture is too weak to be of much value here, I think. Oh well.

Re:Saw this coming

[babbage]

Nice .sig there, "Blech" Mison. :)

(Do not leave there is no (oidvay) cabal.)

Re:So how does Apache cope on Windows?

[babbage]

...and upon about 30 seconds of research on SecurityFocus (which should have been done first here, doh!), it seems that case insensitivity might not be an issue on Windows after all:

"Tested against Apache 1.3.20 on Windows 98 SE (has case insensitive fs) appears not to be vulnerable."

The posts on SecurityFocus don't illuminate how the Win32 version of Apache gets around the problem, but I'm sure some enterprising soul could find the saving code in the source somewhere...

Saw this coming

[babbage]

This is just growing pains -- old school Mac used a case-insensitive filesystem, newschool Mac has to preserve support for both old HFS and new UFS. (Other Unix tools are hitting the same problem whenever case [in-]sensitivity comes up -- the MacPerl people for example are working through it at the moment, too...)

This is a problem that Apple saw coming, and handled, sorta, with a custom mod_whatever that tried to address the problem. Why they didn't release it (either as source or, if necessary, as a binary) with OSX client is a big question, and an unfortunate decision on their part, but at least it already exists. Maybe this negative publicity will get them to release it &/or fold it into the next update to the operating system.

Really though, if you're using OSX for the new &/or Unixy stuff, then you need to run it on a UFS partition so that things like this won't bite you in the ass. If you need support for OS9/Classic, then either it or the Unix stuff needs to go onto a different partition. If not, you'll constantly be hitting these sorts of problems...

Re:Saw this coming

[kilgore_47]

Maybe this negative publicity will get them to release it &/or fold it into the next update to the operating system.

I wish. For some reason, no matter how nice apple seems they're still corporate bastards when it comes down to it. "Think Different" my ass.

-

Re:Saw this coming

[kilgore_47]

Uh, maybe you missed http://www.opensource.apple.com/, but apple has released quite a bit of code and none of it is GPL'd. The GPL is the last liscense apple would use!

-

Interesting bias

[Microsift]

The headline makes it sound like the error was intentional, this is clearly in the wrong topic as well, should have been bug!

So how does Apache cope on Windows?

[Pogue Mahone]

So how does Apache handle the Windows (NT or whatever) filesystem. Last time I looked that was case-insensitive too. The code must be there already - just a compile time option perhaps? Or is this also a security hole waiting to be exploited?

--