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."

8 of 222 comments (clear)

  1. Re:Summary For The Lazy by mingot · · Score: 5, Insightful

    Won't matter. Most malware is installed via the user while installing the latest screensavers, emoticon packs, and browser toolbars. Nothing will ever be able to defeat the uneducated user.

  2. deja vu? by neongrau · · Score: 5, Insightful

    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?

  3. The "Anti-Lock Brakes" of OS design... by argent · · Score: 5, Insightful

    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?

  4. Address space layout randomization by owsla · · Score: 5, Informative

    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.

    1. Re:Address space layout randomization by argent · · Score: 5, Insightful

      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.

  5. Re:Summary For The Lazy by virgil_disgr4ce · · Score: 5, Insightful

    It's not the interface's problem, it's the fact that 98% of computer users do not want to and will not learn anything about their computer. Some people will actively refuse to learn anything. So in light of that, the root of the problem is far, far deeper :(

  6. Re:Summary For The Lazy by erroneus · · Score: 5, Interesting

    Having knowledge is having additional responsibility. It took me quite a while to arrive at that conclusion, but if people can claim they didn't know or don't understand something, they are therefore not responsible for it. This goes well beyond knowing about computers and into all facets of life. For me, knowledge has always been important and desirable, so it was really hard to understand why the majority of people don't want any. But I believe I've hit upon the precise essence of why people don't want to know anything... they don't want it to be their fault.

  7. Re:Summary For The Lazy by 99BottlesOfBeerInMyF · · Score: 5, Insightful

    Whoa there, tiger. You seem to be missing the point of my post: that most users don't know what an "executable" or "data file" is in the first place, and will likely not use the computer often enough to learn by exposure.

    How would they know if the user interface makes no distinction? You have to fix the UI first, to reduce the level of education needed to something reasonable. Seriously, most user want to run programs they don't completely trust and their inability to do so is one of the primary causes of insecurity. Current OS's make this incredibly common task very, very onerous. Really the easiest way to do that these days is to but a VM, install it, configure it appropriately for the program you want to run, create a new image, install an OS, install the program within the OS, and finally run it. That takes money and significant skill and time and is simply too onerous for the normal user.

    But any interface nonetheless requires some degree of learning--"intuition" in interfaces is only, in fact, "familiarity."

    You can call it whatever you want, but different interfaces and the functionality they connect to make a huge difference in how much education, skill, time, and money it takes to compute securely. Until OS's catch up, people constantly calling for education and blaming users are part of the problem, more than the solution, IMHO.