Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Security Apple

Snow Leopard Missed a Security Opportunity 304

Posted by kdawson
from the where-did-you-put-it-what-you-know-where-do-you-think-oh dept.
CWmike writes "Apple missed a golden opportunity to lock down Snow Leopard when it again failed to implement fully a security technology that Microsoft perfected nearly three years ago in Windows Vista, noted Mac researcher Charlie Miller said today. Dubbed ASLR, for address space layout randomization, the technology randomly assigns data to memory to make it tougher for attackers to determine the location of critical operating system functions, and thus makes it harder for them to craft reliable exploits. 'Apple didn't change anything,' said Miller, of Independent Security Evaluators, the co-author of The Mac Hacker's Handbook, and winner of two consecutive 'Pwn2own' hacker contests. 'It's the exact same ASLR as in Leopard, which means it's not very good.'"
This discussion has been archived. No new comments can be posted.

Snow Leopard Missed a Security Opportunity

Comments Filter:
  • Two week old "news" (Score:5, Informative)

    by Anonymous Coward on Wednesday September 16, 2009 @07:34AM (#29438489)

    The summary alleges Miller said it "today". Except he didn't.

    The article linked to is dated September 14, which means he allegedly said it 2 days ago. Except he didn't.

    He actually said it *two weeks ago* on August 29th. [theregister.co.uk]

    Wake up, editors!

  • Justified praise (Score:5, Informative)

    by Chrisq (894406) on Wednesday September 16, 2009 @07:43AM (#29438571)
    From Address space layout randomization [wikipedia.org]:

    Microsoft's Windows Vista and Windows Server 2008 have ASLR enabled by default, although only for those executables and dynamic link libraries specifically linked to be ASLR-enabled.[citation needed] This did not include Internet Explorer 7 on Windows Vista prior to Service Pack 1; ASLR and DEP are both disabled for application compatibility purposes. Newer versions, including Internet Explorer 8, enable these protections. A registry setting is available to forcibly enable or disable ASLR for all executables and libraries. The locations of the heap, stack, Process Environment Block, and Thread Environment Block are also randomized. A security whitepaper from Symantec noted that ASLR in 32-bit Windows Vista may not be as robust as expected, and Microsoft has acknowledged a weakness in its implementation.

    It appears that only OpenBDD and some hardened Linuxes (not mainstream distributions) have a complete implementation.

  • Re:Oops (Score:3, Informative)

    by Anonymous Coward on Wednesday September 16, 2009 @07:46AM (#29438601)

    "Microsoft perfected nearly three years ago"

    OpenBSD has had this for many, many years. Microsoft used the OpenBSD code as a starting point for their own product. Love the BSD license!
  • by Anonymous Coward on Wednesday September 16, 2009 @07:46AM (#29438607)

    OpenBSD has been using these techniques a lot longer than Microsoft has, so I suspect that there is not (yet) an issue of patents to be licensed.

  • by Anonymous Coward on Wednesday September 16, 2009 @07:48AM (#29438629)

    ASLR makes executing code on the stack quite a bit more difficult, regardless of what privileges the program being exploited may have. Also makes calling libaray functions and pretty much anything in RAM far more difficult for a hacker. Page protection doesn't protect against these attacks per se.

  • Re:Here they come... (Score:5, Informative)

    by Anonymous Coward on Wednesday September 16, 2009 @07:57AM (#29438697)

    1. You identify a system API that has a local escalation vulnerability. These aren't that uncommon and because they cannot be directly exploited remotely they're not generally as high of a priority.

    2. You identify a vulnerability in a service or other application that permits execution of arbitrary code remotely.

    3. You exploit the remotely exploitable vulnerability with a payload that calls into the known mapped address of the system API with a second payload in order to escalate to root and then execute a third payload with those increased privileges to outright p0wn the machine.

  • by drinkypoo (153816) <martin.espinoza@gmail.com> on Wednesday September 16, 2009 @07:58AM (#29438709) Homepage Journal

    Linux's implementation of ASLR is substantially inferior to Windows Vista/7's, which was covered the FIRST time this guy won the pwn2own contest. However, it is far superior to OSX's, which appears to not really do anything useful, and which appears to have not even changed since it was discovered that OSX ASLR is useless. Please try to keep up, or don't comment. Thank you.

  • Re:Justified praise (Score:2, Informative)

    by gabebear (251933) on Wednesday September 16, 2009 @08:06AM (#29438785) Homepage Journal
    Microsoft's does appear to be much better, but hardly perfect...

    The pwn2own article mentions the Win7/IE8 ASLR/DEP vulnerability that was patched before the final version of IE8 was released http://dvlabs.tippingpoint.com/blog/2009/03/27/pwn2own-ie8-exploit-foiled-is-the-browser-finally-secure [tippingpoint.com] . Evidently the hack still works if launched from an intranet.
  • by Doc Ruby (173196) on Wednesday September 16, 2009 @08:07AM (#29438795) Homepage Journal

    technology that Microsoft perfected nearly three years ago

    If there's a phrase that should trigger skepticism, that's it. ASLR isn't "perfect", and has been reported (and confirmed) exploited [dslreports.com] as recently as 7 months ago:

    March 24, 2009 -

            quote:Internet Explorer 8 "critical" flaw in final version

            Microsoft confirmed that the vulnerability exists in the official release, said Terri Forslof, a researcher at TippingPoint, which sponsored the Pwn2Own contest that challenged competitors to find bugs in either web browsers or mobile devices

            "This is a single-click-and-you're-owned exploit," she told SCMagazineUS.com on Tuesday. "You click a link in an email or simply browse to a website, and your machine is compromised. This meets Microsoft's 'critical' bar [in its vulnerabilities and rating system]."

            The exploit apparently defies Microsoft's DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) technologies -- two features added to IE8 to prevent memory corruption vulnerabilities.

            "Once the browser was compromised, we handed over the exploit to Microsoft immediately, on site," Forslof said. "They went back and reproduced it and called to verify that the vulnerability was present. We retested again on the released version of IE8 that went live on the following morning and verified that the vulnerability was in it as well."

  • by FelxH (1416581) on Wednesday September 16, 2009 @08:15AM (#29438871)

    address space layout randomization I though this was a feature in OS X 10.5? Was it not implemented or just not implemented as well as other OS's? I remember hearing about it as a feature for 10.5.

    From TFA:

    Two years ago, Miller and other researchers criticized Apple for releasing Mac OS X 10.5, aka Leopard, with half-baked ASLR that failed to randomize important components of the OS, including the heap, the stack and the dynamic linker, the part of Leopard that links multiple shared libraries for an executable.

  • by risinganger (586395) on Wednesday September 16, 2009 @08:17AM (#29438917)
    Not that I wish to stop you frothing at the mouth, but I'd recommend viewing one of the posts above yours [slashdot.org].
  • Re:Oops (Score:4, Informative)

    by supernova_hq (1014429) on Wednesday September 16, 2009 @08:27AM (#29439045)

    Praise for MS by kdawson.

    There fixed that for you.

  • Silly ASLR (Score:3, Informative)

    by Ancient_Hacker (751168) on Wednesday September 16, 2009 @08:38AM (#29439203)

    ASLR is sorta like moving the location of the barn door, while keeping it wide open.

        Hint: The cows can still get out.

    Perhaps the guys at Apple realize this and give ASLR a low priority for implementation.

    Even so, adding ASLR to the Apple OS is something they could do with relative ease-- change the kernel and user-space mallocs() to be less predictable, munge the call stacks tobe less predictable, etc, etc, etc,---- mostly stuff that can be done with 50 lines of code here and there and not too many other places.

    But again, it would be much more efficient to put that effort into closing any open barn doors, rather than painting the open gateways in random colors. Every five seconds.

  • by viralMeme (1461143) on Wednesday September 16, 2009 @08:42AM (#29439269)
    "Apple .. failed to implement fully a security technology that Microsoft perfected nearly three years ago in Windows Vista"

    Address space layout randomization is a technique to randomize memory addresses of the base of the code, stack, heap, and libraries. First used by PaX and OpenBSD [laconicsecurity.com]
  • by Sancho (17056) on Wednesday September 16, 2009 @08:50AM (#29439355) Homepage

    Most Slashdotters don't understand what security is. Security and safety are not synonymous. Obscurity may make you safer, but it does not make you more secure.

  • by incripshin (580256) <markpeloquin@@@gmail...com> on Wednesday September 16, 2009 @09:08AM (#29439655) Homepage

    Tagging doesn't work for me anymore, so I picked the post with the most use of the word 'obscurity'.

    This is not security through obscurity (STO). STO can always be exploited when you know how the algorithm works. Address space randomization cannot be exploited (immediately). You still have to start the executable maybe hundreds of times before the exploit works. This is easy if it's some short piece of code you've crafted yourself, but with real applications, it's not so simple.

    Imagine a hack where you send some exploit to somebody over IM. If it doesn't work, the IM client *will* crash as it tried to execute some random portion of memory. How are you going to try your exploit at a different address now?

  • by enrgeeman (867240) <slashdot@enrgeeman.com> on Wednesday September 16, 2009 @10:19AM (#29440635) Homepage

    I'm pretty sure he was referencing STDs, based on the "mac users are gay" idea. whatever.

  • by Anonymous Coward on Wednesday September 16, 2009 @11:03AM (#29441307)

    > Lets combine that most people don't update their Linux boxes as quickly as Macs or Windows too.
    > As Linux is a server OS and for the most part it will just kinda sit there in the background without much looking at it and as long it is running things are fine.

    A ridiculous and unfounded assumption! Maybe *you* leave your server just sitting in a corner, but *real* sysadmins take care of their machines. Most Linux distros have great updaters that check *daily* for security updates - not just to the "core" of the OS, but for *every* installed package. Windows *still* doesn't/can't do that, but it's getting better.

  • by brkello (642429) on Wednesday September 16, 2009 @11:07AM (#29441381)
    Huh, your post makes it seem like you know what you are talking about but I don't really think you do. There are multiple ways to exploit OS's. Just having privilege escalation doesn't solve every security problem. ASLR is a technique that addresses a specific vulnerability that allows you to get arbitrary code execution. This is just one of many techniques to gain root and ASLR (as far as I know) is the most effective way of addressing this issue. There are some issues with it but it isn't really a performance thing, more of a compatability thing and being used uniformly by the applications.

    Should Apple implement it? If they want to be secure, then yes.

    Quite frankly, Macs are more secure against certain classes of attacks. Making a global statement about it being more secure is wrong, though. Macs enjoy being less of a target since they are a small number of them out there. To think they are safe is pretty naive. The guy has proved multiple times he can hack them without much trouble.
  • Re:Silly ASLR (Score:3, Informative)

    by shutdown -p now (807394) on Wednesday September 16, 2009 @11:33AM (#29441811) Journal

    ASLR is sorta like moving the location of the barn door, while keeping it wide open.

    Yes, which is why you keep the door closed. The point of ASLR is to provide some extra degree of protection in case someone accidentally forgets to close the door. Since it happens every now and then anyway (and, yes, in OS X too), it makes sense to have some additional protection.

    Also, you rather underestimate the effect of ASLR. It makes reusable fire-and-forget exploits of buffer overruns (which are the single most common source of security issues) extremely difficult to write.

  • by VertigoAce (257771) on Wednesday September 16, 2009 @01:36PM (#29443853)

    In order to "look in the same place", you need to have code that does the looking. The NX bit will prevent arbitrary code from executing on the stack. One way to get around NX is to overrun a buffer and replace the return address of the stack frame with a known function address that does what you want. In order for this to work, you need to know the address in advance of the attack. ASLR makes it difficult to predict this address.

  • by AnalPerfume (1356177) on Wednesday September 16, 2009 @04:31PM (#29446643)
    This is not about being able to install apps, or setting a Mac up to do things. It's about someone with malicious coding intent knowing that by examining ONE Mac and writing their app to exploit a file that came with it, be it a library file, a bug in a config file, or a tweak to something like Safari. They can rely on EVERY Mac having those files installed, configured with the same exploit. Even if you install and use Firefox, do you remove Safari? What about iTunes? Even assuming you do that with the applications, the culture still exists for the stuff under the surface that you can't remove.

    By comparison, if someone finds an exploit in Gnome in Ubuntu, for the short time that the window is open, it may only affect Gnome, but in other distros. It may not affect Fedora because of the way Fedora package Gnome. People who don't use Gnome at all won't be affected at all. If you find an exploit in Firefox on Fedora, it may affect every Fiefox, it may not for the same reasons, the distros package their own, often with their modifications. Those who don't like Firefox don't have it installed and are not affected.

    Updates are going on all the time from both the distribution end and the upstream end which means that there's every chance someone else will spot the exploit you have, and patch it before you can get your malware written and deployed. Linux is a hugely diverse setup, which makes it a small moving target. You're not going to waste your time trying to hit that, specially when it all the development happens in the open.
  • by dave562 (969951) on Wednesday September 16, 2009 @05:39PM (#29447573) Journal
    Popularity has very little to do with why a system gets viruses or there would not have been as many viruses for the old Mac systems and there were a shit load of them for OS7, 8 and 9.

    You have to remember that the old OS7, 8 and 9 systems WEREN'T connected to the internet. Also, virus writers in the 1990s were writing their virii in x86 ASM code. The Macintosh computers were running Motorola processors. In this day and age, the people writing serious security exploits are criminals and governments. They want money. They want information. What information is kept on a Mac that anybody cares about? Some InDesign files? Oooooo yeah, there's a real huge market for stolen graphics files. Maybe someone has the OSX equivalent of Quickbooks? Yeah, that's a real gold mine right there. Until OSX is running ERP and financial systems, very few people are going to bother to target it. The payoff simply isn't there.

  • by rainmaestro (996549) on Wednesday September 16, 2009 @06:13PM (#29447945)

    Yup, when it comes to servers, the admin is more important than the OS. If the admin knows what he's working with, he can keep even the worst OS more or less secure.

    We had a similar issue at work. Our servers were all working off a group policy that allowed AU. It was set up that way long before I started there. Sure enough, AU took down the mail server one day while forcing a reboot after a patch. Lesson learned.

    The biggest threat to security is an admin who isn't intimately familiar with their systems. We've all been there at least once =)

If you're not careful, you're going to catch something.

Working...