Shostack + Friends Blog Archive

The Approaching Apple OSX86 Security Nightmare

In the midst of an excellent long article on how the Wine Windows emulation layer will interact with OSX86, (“I invite you to wine“), Wil Shipley writes:

When you can run Windows apps on Mac OS X, you’ll still be protected by Mac OS X. Viruses are going to be dead. D-E-D. Ok, yes, there are certain kinds of pseudo-viruses (the kind where they trick dumb people into running them) that will still exist, but even those will NOT be able to infect the whole system, because even you don’t have access to the whole system. The worst that’ll happen is your personal account will get messed up, and you’ll have to nuke it and create a new user. And then learn not to open mail messages that say, “Free PRON, just launch the executable!”

These sorts of claims are common and misguided. As Apple becomes more popular, and moves to X86, attacks on MacOSX will increase dramatically in their frequency and virulence.

There are three design choices that Apple has made differently than Microsoft that offer quite a bit of security. The first is that Apple has no equivalent of ActiveX. That means that it’s much harder to get the web browser to execute arbitrary code for an attacker when the intended victim is on OSX than when the victim is on Windows. The second is that while the default user is in the “admin” group, the admin group is not extremely powerful. The third is that, often, to install software, you need to type your password. That’s because the admin group is not powerful enough for some important install types. Usually. For some install types. Not other times. And that ‘not other times’ will be the path that attackers use. It’s the path that you use dragging apps from a dmg (disk image) to /Applications.

The default permissions on both /Applications and /Library are (0775, root:admin). [Typo corrected.] Neither is sticky.[1] So what does that mean? Well, the first thing it means is that an attacker can likely write to anything under either directory (or replace it with a modified copy.) So Shipley’s advice, “The worst that’ll happen is your personal account will get messed up,” is incorrect. Because your personal account can drop malware into /Applications or /Library and destroying your old account won’t get rid of it. I’m not an expert on what’s in /Library, or how it interacts with (the more tightly permissioned) /System/Library, but it seems likely that infection of /Applications would be, at best, time consuming, to clean up.

I should mention, I don’t mean to pick on Mr. Shipley, I’m just using him as an archetype. His claim is correct: There are parts of the OS that you don’t have direct access to, but it’s also misleading, because there are important parts that you can change.

I believe that /Library/StartupItems/ will be started before a user logs in. That’s a fine place for some malware to live. Now, that malware will want additional privileges. Having just updated Flash, which is loaded in all my browsers, it didn’t ask for a password. I’m guessing that you can hook the finder from /Library, but not the actual filesystem (as seen by unix commands like ls.) For those privileges which a subset of malware (rootkits) will want, you’ll need to become root. And that’s harder, but I fully expect that more of the SetUID programs on the system will have issues. When I say more, at least CVE-2003-0088 had a very simple mistake (AusCERT’s archive of the advisory.) Now, that was a while ago, but since DaveG left @Stake, I don’t know how much attention is being paid to the 25 or so setuid apps on the system that appear to be from Apple.

I do know that the attention paid to them will go up dramatically when OSX86 becomes available. There are several things that will drive that. The first is that more people will have machines that can run the OS. (Apple’s DRM systems to ensure that their code only runs on their machines will fall like leaves. Remember, the people who find new problems read disassembled machine code for fun.) So, more people with more machines. Those people will have better analysis and disassembly tools. Tools that have been honed for years. That’s the second thing. The third thing is that comments like Shipley’s cause researchers to want to find problems, to “show those Mac users.” The final driver of increased attention will be that there will be more Macs to attack.

Now, that increased attention is going to be turned against an OS that hasn’t evolved to resist it. It’s not going to be pretty. My researcher colleagues who have poked at MacOS have had quite rude things to say about it. Apple’s response to the dmg issue wasn’t impressive. Apple’s security issues with Dashboard widgets were an embarrassment. I hope that Apple has used the interval wisely. But I suspect that Apple and the faithful are in for an unpleasant surprise.

[1] I wasn’t sure if I’d adjusted those, so I checked:

% ls -ld /Applications/ /Library
drwxrwxr-x  57 root  admin  1938 31 Oct 17:27 /Applications/
drwxrwxr-x  47 root  admin  1598 25 Sep 15:24 /Library

You can validate that these are shipping permissions with the ‘lsbom’ (ls Bill Of Materials) command:

% lsbom /Library/Receipts/Essentials.pkg/Contents/Archive.bom | grep './Library'
% lsbom /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom | grep './Applications'

(I’m told that /Library is sticky in 10.4, which is a fine improvement.)

Originally published by adam on 9 Nov 2005
Last modified on 9 Nov 2005
Categories:   information security   Macintosh   Uncategorized