Shostack + Friends Blog Archive


The Approaching Apple OSX86 Security Nightmare

chased-mac.jpgIn 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/ | grep './Library'
% lsbom /Library/Receipts/BaseSystem.pkg/Contents/ | grep './Applications'

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

8 comments on "The Approaching Apple OSX86 Security Nightmare"

  • Chris Walsh says:

    You say the dirs are mode 0755, but your “ls -l” output shows 0775.

  • Adam says:

    That was a typo. My argument makes a lot less sense if the perms were actually 755, and slightly less sense when the perms are 4775. But only slightly, unless all the interesting directories are pre-created with strong permissions.

  • calzone says:

    I’ve often wondered if there’s anything keeping someone from creating a program that masquerades as the OS X installer and requests an admin username and password and then proceeds to happily issues sudo commands all over the place.
    All it would take is getting someone to agree to install that program once. Then, it would claim that it needs to run an additional installation for its first run. Then it would pretend to be the installer, ask for your admin username and password, and it would be game over.

  • Bryan says:

    Note that, at least with 10.4.x, /Library/StartupItems stuff needs to be owned by root (a dialog will pop up for anything with incorrect permissions).
    However, the best vector would be adding some malicious code in as one of the various plugin bits (Contextual Menu plugins, Input Method plugins, etc), as those can affect all users and do non-fun things…

  • superstupid says:

    The expression “your personal account will get messed up, and you’ll have to nuke it and create a new user” is a bit misguided, because typically *all* the data you want to keep safe (your documents, your photos, your music, your passwords etc.) is in (or accessible by) your “personal account”.
    The rest of the system is the part that (with some expenditure in time and effort) can be reinstalled and exactly reproduced.
    Your personal data cannot. And, maybe worse, malware that reads your private data and sends it out to “someone” only needs to access your data, not root’s.

  • Chas says:

    “I believe that /Library/StartupItems/ will be started before a user logs in”
    How can this be when /StartupItems/ only exists in the user’s Library, not in the global Library? Therefore, any malware that attempts to use this approach cannot execute before a user logs in…or have I missed something?

  • Adam says:

    I have a /Library/StartupItems, which contains tor and privoxy. I have no ~/Library/StartupItems.

  • Aram Fingal says:

    Only three design choices that Apple made differently than Microsoft?
    How about the following?
    OS X uses a true POSIX permissions system and has no Registry.
    The root user is disabled by default.
    OS X is built on top of BSD UNIX which was designed from the ground up with security in mind because it was originally a server OS.
    The BSD foundation of OS X is open source and, therefore, publicly peer reviewed for security flaws.
    It is much easier in OS X than in Windows to work as a non-admin user and still be able to do everyday tasks.
    OS X has a much more modular design which makes it easier to remove things that you don’t need. You can’t be hacked through flaws in software you don’t have.
    OS X includes an independent (from UNIX) encryption system which includes the Keychain, File Vault and encrypted disk images that can put things out of the reach even of root. This system also makes it relatively easy for ordinary users to manage passwords in a way that is more secure than what most people do. Some software already taps into this system to make deployment more secure on OS X than on a generic UNIX system. I’m sure more software will do so in the future.
    I’m sure I can come up with more if I think on it a bit but these are the first few things that come to mind.

Comments are closed.