Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Apache security hole in OS X Client UNIX
Stefan Arentz has discovered a security hole in Apache which affects Mac OS X Clients serving pages off of HFS+ formatted volumes and using .htaccess for protecting directories. Since HFS+ doesn't care about capitalization, but Apache does, you can access a protected directory (say "test") by using a version with capitalization ("tEsT"). Apache won't see this as a request for a protected directory, and HFS+ will return the file, since it doesn't care about the capitalization. Instant password protection workaround.

Stefan has posted a thorough description of the bug on SecurityFocus; check out the article for more information, along with a suggested workaround until Apple releases a patch of some sort (if they do).

If you are serving pages from an HFS+ disk, protected with .htaccess files on your OS X client box, this article and workaround are a must read!
    •    
  • Currently 4.67 / 5
  You rated: 5 / 5 (3 votes cast)
 
[2,938 views]  

Apache security hole in OS X Client | 8 comments | Create New Account
Click here to return to the 'Apache security hole in OS X Client' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
This is gonna be a recurring problem...
Authored by: babbage on Jun 13, '01 10:07:41AM
See also the brief discussion on Slashdot: <me>

This is just growing pains -- old school Mac used a case-insensitive filesystem, new school 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...

</me>

And it's worth adding that, apparently, the Win32 version of Apache -- which also generally (always?) runs on a case-insensitive filesystem -- doesn't have a problem with this. The answer why isn't clear yet, though anyone is welcome to compare the source code of the Win32 and Unix versions for any interesting variations. Something in the filesystem routines in the Win32 version could probably be ported to the OSX port of Apache, which should otherwise be about the same as stock Unix.

(Wow that red is hard to read. You're using some kinda funky stylesheet on this site, Rob... :)

[ Reply to This | # ]

Let's just hope...
Authored by: sjonke on Jun 13, '01 01:36:46PM

... the fix isn't to make OS X case sensitive - ugh!

Apple needs to build in some safeguard, the intent of which wouldn't be to make case-dependent applications work, but rather to block them out so that they can't be run. In order to run they would have to be changed to be non-case-dependent. Besides, we want them aquafied anyway. Push forward, don't fall back.

Steve



[ Reply to This | # ]
Did You Check This???
Authored by: Anonymous on Jun 14, '01 08:40:19AM

Perhaps I'm overlooking something here, but I just tried accessing several .htaccess pages using various combinations of lower/upper letters and they all came back with a basic login request. So what's the problem? I just can't seem to gain a similar fever of paranoia with this post. What, again, seems to be the problem? Perhaps you should be looking into your Apache setup rather than dropping the entire blame on OS X; have you even uncommented the proper access restrictions? If it is a problem, please document it a little more fully.

Cheers,
ptervin



[ Reply to This | # ]
Did You Check This???
Authored by: atl on Jun 14, '01 01:11:40PM

I, too, had trouble triggering the bug on my HFS+ box. No matter how I capitalized my protected directory, I couldn't avoid the login prompt.
I'm not saying it's not a problem. I'm only saying that it's not universal.



[ Reply to This | # ]
Did You Check This???
Authored by: Anonymous on Jun 14, '01 07:31:15PM

me too...couldn't get the 'bug' to appear. All my protected directories still forced the login/passwd sheet to appear.

Y



[ Reply to This | # ]
Did You Check This???
Authored by: FlyBoy on Jun 15, '01 10:13:49PM

I also don't have any case sensitivity problems with several .htaccess protected pages on my intranet Apache web site. I always get the authentication screen (in OmniWeb) no matter how I alter capitalization for the desired directory.

FlyBoy



[ Reply to This | # ]
Did You Check This???
Authored by: Anonymous on Jun 16, '01 02:55:10PM

Just wanted to point out here... as I understand it, the bug is not with ".htaccess"-protected directories, but ony with directories protected using Location or Directory tags specified in httpd.conf (Apache's global configuration file). When you use .htaccess files, performance is slightly degraded. The article points out that the more performant security methods (specifying Location or Directory tags in httpd.conf) are the ones that have the security hole.

Anyway, Apple's recent open-sourcing of mod_hfs_apple.so seems to address the problem for those who care to install it.



[ Reply to This | # ]
Solution on Macintouch
Authored by: atl on Jun 15, '01 07:12:49AM
No doubt this has been reported elsewhere, but John Siracusa wrote into Macintouch pointing to mod_hfs_apple.c at http://www.opensource.apple.com/projects/darwin/darwinserver/ I haven't verified it, but I wanted to pass the word on.

[ Reply to This | # ]