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.
Signed kernel modules would not just stop malware but it would stop some of the hacked (and custom written) kernel modules being used to get OSX to run on non apple machines (or being used to make the experience of using OSX on those machines better)
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?
Apple already does address space layout randomization in Leopard (Mac OS X 10.5)
See "Library Randomization" on
http://www.apple.com/macosx/features/300.html#security
Notice that the new security features list also includes code signing and sandboxing. The technology is there, it's just not setup throughout the system.
It was always going to eventually happen. Given the increasing market share of OS X it was only a matter of time before the hackers got interested. Yet even they had to wait till a sufficient base of idiots got into OS X to make their job easier. I know people who significant other has trashed home PCs more than once opening attachments or running attachments even after all the pop ups. Note the more than once.
People forget or get in a hurry. Its the hacker's job to exploit that nature. That makes it difficult for the owners of the OS because even if you require a password/etc to execute something many people will just do that, type in the password regardless. Its like the story of the young girl who was a latch key kid, told to never ever let people in the house while mom was gone. Yet she did three times and even denied it until shown the film showing these people being let in. Worse, she didn't recall because it was so automatic. She was distracted by something else and that focus let her pass over doing what was right.
I look at it this way on my iMac, if that password prompt comes up and I didn't click initiate it from some update I know came from Apple or I was loading a package I downloaded I am going cancel the process. Yet I am quite sure my friends SO would dutifully type the password in. Can't be helped. Sometimes people cannot accept they did something wrong even when you show them
* Winners compare their achievements to their goals, losers compare theirs to that of others.
hardware-enforced Non-eXecutable memory?
Unless you can could turn it off, it just sounds like DRM.
This isn't DRM. This is what prevents a stack overflow or buffer overrun from executing code. There is absolutely nothing evil or even potentially evil about it. Marking your data segments 'NX' means that they can't be executed, even if something 'bad happens'.
mandatory code-signing?
Again this isn't evil. I think it would be great if ALL code always had to be signed. It would pretty much kill morphic virii, and put a real dent in the spread of rootkits etc.
The key to 'good' vs 'evil' with mandatory code-signing is who holds the keys. If I hold the keys to MY computer, then there is NOTHING WRONG with mandatory code-signing, because if there is something I want to run that hasn't been signed by [OS-vender] I can sign it myself to run on my computer, my network, my enterprise...
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 ]
No word yet on MacOS 10.8 Cougar, to be designed with the "active" older woman in mind.
You can run it via SSH as long as someone is logged into the console.
If you can ssh in, you already have local access.
"Local" is the counterpart of "remote". A "remote exploit" is one that you can perform without already having local execution access on the machine.
What you are talking about is "physical access".
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).