Slashdot Mirror
How to Save Mac OS X From Malware
eXchange writes "Well-known hacker Dino Dai Zovi has written an article at ZDNet discussing last week's discovery of a critical threat to Mac OS X, and another announcement of a Trojan horse exploiting this discovery. He suggests that Snow Leopard, or Mac OS X 10.6, should integrate more robust means of preventing malware attacks. Some of the suggestions he has include mandatory code-signing for kernel extensions (so only certified kernel extensions can run), sandbox policies for Safari, Mail, and third-party applications (so these applications cannot do anything to the system), and some lower-level changes, such as hardware-enforced Non-eXecutable memory and address space layout randomization."
Make Mac OS X like Windows Vista (64bit Vista has almost all of the things listed in his article).
If it does get implemented, it'll be interesting to see how Jobs talks it up since Apple wouldn't have been first.
Isn't that excactly the same stuff Microsoft talked about years ago and many ppl on slashdot cried "foul!" about it?
But then again it all makes sense for Apple. The iPhone's App Store pretty much does all that. And when it works out Apple might just start an Mac App Store. No executable program launchable if it doesn't originate from the App Store. Or only in some considered insecure sandboxed VM. That could even work, but is that really what users want?
please, the mach kernel was hacked to bypass TPM, it'll be hacked to bypass driver-signing.
It's a local-only root privilege escalation exploit.
If you're in a position to exploit this, you're already running code with full local user privileges.
Once the system is penetrated, it's game over. You don't need to get root access, or Administrator access, or even break out of the "Reduced Security" sandbox to win basically everything that the guy writing the malware actually needs. Multiuser security is there to protect users from each other, not from themselves.
Recent studies of anti-lock brakes and safety have discovered that ABS doesn't improve safety in general. It improves braking, by letting people brake faster and smoother, but people get used to it and enough people end up depending on ABS that they end up just braking later and when they need the extra edge from ABS they've already used it up.
Before going off half cocked proposing more layers of complex software that has to work correctly to maintain system integrity (because if it's there, enough software developers will end up depending on it) how about looking at what features of systems promote malware distribution? Design applications so they are inherently safe, rather than filling them with holes and backfilling with kernel patches and warning dialogs?
A car with an uneducated driver is a potential very powerful weapon.
A computer used by an uneducated user... well at worst he'll screw his computer. Maybe piss off some innocent other web users with the spam mail that the zombied PC will spit. And even eventually might got some money stolen if too much personal data is spied.
But unless the random guy is operating a computer controlling a nuclear core (and those already *are* selected and trained to be good at their job), it's very unlikely that the screw-up will result in deaths.
That's why you won't see computer license any time soon, because the perceived risk (nobody will die at the end) is much lower than the perceived advantage (internet usage has become pervasive, it's so important and useful that anyone *must* have access to it).
The only thing that you could remotely imagine is a tiered approach to internet security :
the global net is accessible to anyone, but only common service are found on it. Special service are connected to a different network, which is more secure and more reliable but does necessitate special clearance.
Think in terms of "Internet freely available for all, Internet2 & GEANT only for hospitals, nuclear reactors and those who pass some license".
But you can't just shut people of internet because our society relies on it and anyway, nobody will die.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
On OS X, sandboxing is different. Please read couple of pages from Apple mailing lists before comparing it to its bad photocopy. OS X hasn't got a problem with Applications running under normal user account so there is no community to educate with stick (like MS does).
Safari.app will be able to say "Here are my directories and the system calls I will make". So Safari won't even see a Framework or System folder. Way more detail at http://www.318.com/techjournal/?p=107
On OS X Leopard, there are couple of deep level technologies already having sandbox technology (spotlight and bonjour) and Apple is preparing it for general developer use.
OS X "stupid security" dialogue works well, so damn well that it is able to figure out Adobe AIR Applications user installed over the web. The "stupid dialogue" could be a life saver in future. I am not speaking about the Windows horrible copy.
Code signing is not like the Verisign pyramid scheme on Windows, ANY Developer can sign their application free. People actually adopt it, even including Adium X like open source applications. There is no "Apple certified" or "Verisign Secure" junk, it is application signing which is meant to benefit the user and developer. By signing it, you just make sure your files aren't tampered after user trusts it so no lamers taking advantage of your application (and users trust). There are no other advantages, OS X treats your Application just like unsigned Applications. It is not the signing in Microsoft Windows. If user updates unsigned Application, OS will prompt if he/she wants to grant access since there is no way making sure that it is the same binary from very same developer user trusted at first place. If user updates a developer signed binary in a normal way and the signature is the same, it doesn't prompt.
Read this for more info:
http://adiumx.com/blog/2008/04/adium-application-security-and-your-keychain/
Here's the list of Windows' trusted Root CAs: http://msdn.microsoft.com/en-us/library/ms995347.aspx. Only third-parties are on that list -- not Microsoft.
Code signing is harmless if the machine's administrator is the ultimate authority. Take a look at CertMgr.exe (specifically, play around with the 'import' function). The administrator is the ultimate authority, and this is the case in XP/2003/Vista/2008.
The issue is: whose interests should the OS serve: the OS maker, the user, or (in the case of malware) anyone who manages to get their code onto the machine? If the OS designer answers that question correctly, then there's no problem with code signing (or other whitelisting approaches). I agree. I think you have to admit that MS has addressed these concerns.
Naturally, the author of TFA got it wrong: Most kernel extensions are from Apple anyway and for the few common 3rd party ones, they should be required to get a code signing certificate. Required by whom? A certificate from whom? And the amount of trust delegated to this CA is what? I'd say the author got it right. Your concern is valid, but it's orthogonal to the point of TFA. Code signing is a Good Thing and Apple might implement it -- that's the point of TFA. The third-party approach is the correct way to do it -- that's your point.What's sad is the number of people on /. that crucify MS without realizing that their implementation has already addressed all the things they are complaining about (and has done so from day 1).
I've been using UNIX for 30 years, I've worked on safety-critical software and in the control systems industry for 20 years, and I was solely responsible for network security for over a decade of that. I'm pretty familiar with this stuff.
On OS X, sandboxing is different. Please read couple of pages from Apple mailing lists before comparing it to its bad photocopy.
The problem is that it is not in principle possible to build a sandbox around an application like Safari that would both permit it to do the useful things it is supposed to do and prevent it from doing malicious things.
* If Safari can make connections to websites, then Safari can make connections to botnet peers and engage in attacks on websites.
* If Safari can send mail, it can send spam.
* If Safari can read my keychain, it can read my website passwords and pass them to an attacker.
* If Safari can open my bank's web page, it can transfer money out of my account.
* If Safari can upload files, it can upload them places I don't want it to access.
* If Safari can download files, it can "download" garbage over the files I value.
* If Safari can do the things I need Safari to do, a compromised Safari can do the things I don't want it to do.
A sandbox can not protect the things in my computer that I care about from the applications that manipulate them. The only sandbox that is secure is one that does not allow the application the ability to access any non-volatile resources on my computer, except those that are strictly restricted to the sandbox and not used by any other application. Oh, and it can't make network connections, except in very specific conditions... for example, the Java sandbox lets the application connect back to the originating site.
THAT is a security sandbox.
I don't think I would be happy running Safari or Mail under something like that.
OS X "stupid security" dialogue works well, so damn well that it is able to figure out Adobe AIR Applications user installed over the web.
But you want to run them, don't you, so you go ahead and approve them, and you are trained to approve these dialogs. I've watched that scenario play out time and time again, with the same people coming back to me saying "I clicked the wrong button again, I think I've got a virus".
By signing it, you just make sure your files aren't tampered after user trusts it so no lamers taking advantage of your application (and users trust).
I was building the tripwire configuration for my Cheswick-Bellovin bastion firewall back when Steve Jobs was still at NeXT. I know about the capabilities, restrictions, limitations, and drawbacks of far more pervasive and complete file security mechanisms than what Apple has implemented. Particularly the drawbacks...
If an attacker is in a position to modify my applications, then there is nothing OS X can do to stop him, he has already got he keys to the kingdom. He already has remote root access, however achieved, and he's not going to hide a trojan horse inside Mail.app, he's going to hide it in /private/etc/somethingobscure, running as root, and use Mach injection to patch Mail.app on the fly.
As for your linked story: "If you mess with the Adium binary in any way, you will invalidate the signature, and access to secure resources -- specifically keychain items where your passwords are stored -- will be disallowed by Mac OS X."
That's a hell of a drawback. That by itself is enough to make me hold off installing Leopard until I've got time to look up how to disable that paranoid security theatre.