You are viewing sqlrob

SQLRob - Security flaw in Mac OS X [entries|archive|friends|userinfo]
SQLRob

[ website | Rob and Jen's Place ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Friends Views| People Comics ]

Security flaw in Mac OS X [Jan. 23rd, 2008|09:55 pm]
Previous Entry Share Next Entry
[Tags|, ]
[mood |annoyedannoyed]

I filed this with Apple about a week ago, and since they qualify it as "enhancement", I guess they wouldn't mind me publicizing it. It exists in both Tiger and Leopard, and is probably in every version of OS X.

If you run as a non-administrator (you are running as a non-administrator, right?), you aren't as secure as you should be. When you drag a new app to /Applications, Finder asks you for administrator logon credentials. This is all well and good, and is exactly what it should do. However, what happens next is not, and opens you up for other attacks. This dialog is used only for authorization. The credentials are not used again, and the owner of the application is the current, non-administrative user.

To put this in terms of what may happen. You run Firefox, and install it by copying to /Applications. Since it requires authentication to do this, you've increased your safety, or so you think. Now something takes advantage of an exploit, and tries to overwrite the firefox application to do it's nefarious work. Whoops, it succeeds, and your system is now compromised when it should have been protected. Even Windows gets installing as an alternate user correct, why doesn't Mac?

There is fortunately, a simple workaround. Unfortunately, there is not a "Mac" work around, as I just tested that and that has a security flaw as well. Open up Terminal.App, and use su, sudo and chown to set the proper permissions. I'm sorry for the instructions being a little vague, but I will write out a detailed, automated way so that it's regularly scheduled and no intervention necessary.

The "Mac" way would be to right click on the application, and set the owner in the info inspector. This unfortunately, has a net effect of exactly nothing. The ownership of the directory is changed, but the ownership of the contents is not. The ability of malicious software to change the binary is not in any way impacted.
linkReply

Comments:
[User Picture]From: macbastard
2008-01-24 09:03 pm (UTC)

(Link)

This is very interesting...

So basically, attempting to fix the problem the Mac way just "fixes" the application's "wrapper", but the actual contents of the package are vulnerable?

And Apple thinks the fix for this would be an "enhancement", rather than its actual existence being a bug?

You should submit this to Digg or Reddit or something.
[User Picture]From: sqlrob
2008-01-24 09:34 pm (UTC)

(Link)

The copy bug is what Apple considered an enhancement.

The wrapper being incorrect, I just found last night; I haven't bothered filing yet. If they couldn't see the import of the copy issue, they aren't going to see the import of just fixing the wrapper. Given all the DRM baloney they're pulling, that's all they care about instead of genuine issues. They can find out about this when everyone else does.

I think I'm pretty much to the point that I'm going to report bugs here, not bother filing them. They can find them by looking for them or when somebody releases an exploit. There's too much sweeping under the rug, and I'm not going to submit something just to get it ignored. I'm not even sure bad publicity will influence them, see the Java bug that took more than a year to fix, well after Sun fixed it in the original source.
[User Picture]From: torisutan
2008-01-25 11:12 pm (UTC)

A little bit of exposure for you...

(Link)

Just thought I'd point this out for you :)

Cheers.
[User Picture]From: sqlrob
2009-04-22 01:21 pm (UTC)

Re: A little bit of exposure for you...

(Link)