Apple eliminates CanSecWest Pwn2Own flaws

Apple eliminates CanSecWest Pwn2Own flaws

Summary: Here's a little ditty that was almost lost in the sheer volume of this week's Mac OS X security update: Apple has finally patched the two vulnerabilities used to win this year's CanSecWest Pwn2Own hacking contest.The two flaws were used by Charlie Miller and a German researcher known only as "Nils" to launch successful drive-by download attacks against Apple's Safari browser.


Here's a little ditty that was almost lost in the sheer volume of this week's Mac OS X security update: Apple has finally patched the two vulnerabilities used to win this year's CanSecWest Pwn2Own hacking contest.

The two flaws were used by Charlie Miller and a German researcher known only as "Nils" to launch successful drive-by download attacks against Apple's Safari browser.

[ SEE: Pwn2Own trifecta: Hacker exploits IE8, Firefox, Safari ]

However, according to Apple's release notes, the bug exploited by Miller actually affected ATS (Apple Type Services).

  • ATS (CVE-2009-0154):  A heap buffer overflow exists in Apple Type Services' handling of Compact Font Format (CFF) fonts. Viewing or downloading a document containing a maliciously crafted embedded CFF font may lead to arbitrary code execution. This update addresses the issue through improved bounds checking.

The vulnerability used during Nils' exploit affected WebKit:

  • CVE-2009-0945:  A memory corruption issue exists in WebKit's handling of SVGList objects. Visiting a maliciously crafted website may lead to arbitrary code execution. This update addresses the issue through improved bounds checking.

Mozilla was the first to issue a fix for its Pwn2Own embarrassment.  Microsoft is yet to fix the vulnerability that was exploited via Internet Explorer.


Topics: Apple, Browser, Malware, Microsoft, Operating Systems, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Fault Elimination

    I did see the SVG fix in your article on 10.5.7's release and your
    relaying of Apple's attribution of discovery to "Nils."

    Regarding the IE8 issue, this is difficult to research because the signal
    to noise ratio is real low, but it looks as though IE8 fell on 3/19/09.
    Microsoft's engineers were on site and within 12 hours found the
    problem. 3/20 IE8 was officially released. That Monday, as I
    remember, I read on ZDNet that IE8 fell because some of the security
    features of IE8 were not activated on 3/19 but were activated over the
    weekend and these security measures would have prevented IE8 from
    falling. (I contemplated asking the question why were these features
    off in the Beta/RC cycles, but it may have been a moment of
    snarky weakness.) reported on 3/20 that the engineers
    promised a patch real soon and the site congratulated them on their
    alacrity in the face of Mix09 duties.

    So, I think the Pwn2Own IE8 problem was fixed, but I'm having a
    difficult time proving it one way or the other.

    • More noise

      Do you have a link to the now disclosed vulnerability with status showing
      it was fixed? If not it isn't fixed, no apologising required.

      Please provide link (as the other browsers have).
      Richard Flude
      • Re:

        IE8 in Vista/Windows 7 is not affected but IE8 in XP still vulnerable.
        • Is it fixed?

          I don't read from your links where the IE vulnerability was disclosed or
          fixed. The articles talk about the exploit method (.NET DEP+ASLR bypass
          mechanism) possibly used by Nils to break out of IE's sandbox as being
          blocked (in some versions).

          An aside the DEP+ASLR bypass method was public 12 months.

          Richard Flude
          • Not sandbox

            It is stll not clear whether "nils" broke out of the sandbox or not. Per the contest rules he wasn't required to do so; he only had to demonstrate ability to execute code in the context of the application (IE8). Compromising the browser process without breaking out of the sandbox can be bad enough.

            DEP+ASLR are not sandboxing mechanisms. They are anti-exploit mechanims designed to make it harder to exploit a vulnerability to run code. By using a specially crafted .NET assembly Sotirov demonstrated a way to bypass DEP+ASLR and several other memory corruption mitigation mechanisms.

            As I read this, the actual vulnerability (the memory corruption bug) is still undisclosed. IE8 has closed the door on using .NET assemblies to bypass DEP+ASLR. We know very little about the actual vulnerability used in the "nils" exploit. The .NET assembly bypas is not a vulnerability per se, it is merely a stepping stone to avoid falling into the anti-exploit traps.
          • Of course MS hasn't disclosed that vulnerability.

            It adds to their unpatched vulnerability list. They already won't add 3rd party component vulnerabilities (unpatched or patched), so why would this be such a surprise?
          • Oh man

            They closed the door on the vulnerability the
            very next day. Unrelated to the pwn2own contest
            they had already changed the url handling in

            That makes it far less grave. Indeed then it is
            just a memory corruption bug with possible
            highest impact being terminating the browser

            IE8 users are not vulnerable to the attack. The
            "nils" attack would not have been successful if
            tried against the IE8 release.

            And we still do not know if the changes in IE8
            final from RC removed the attack vector altogether - which is definitely a possibility
            if the vulnerability was in the url handling

            Comapared to that, the Safari bug has been open
            for attack ever since. Indeed since the current
            version of Safari was released and possibly

            <b>IE8 users</b> have been vulnerable to
            attackers crashing web pages since the launch
            of IE8. <b>Safari users</b> on both Windows and
            OSX have been open to <i>arbitrary code
            execution</i> since the the launch of Safari.

            Regarding the "vulnerability list" you need to
            study a little more. Of course the
            vulnerability is added to MSs' list. It has
            probably already been assigned a CVE number. It
            is just not <i>disclosed</i> yet, in what is
            known as <i>responsible disclosure</i>. The
            vulnerability will be disclosed when a patch is
            ready. If indeed there still is a
            vulnerability. If the bug was eradicated with
            the IE8 release I suspect that it was never
            recorded as a vulnerability (in the released

            I was not aware that Apple adds 3rd party
            vulnerabilities to their lists? So Apple counts
            OpenOffice bugs now? No really, Apple has built
            OSX partly of open source code and distributes
            OSX with some open source tools. When they
            distribute code as part of the operating system
            they bloody well <b>count as bugs in their
            offering</b>. They don't get a free ride - if
            they want to leverage the functionality they
            expose their customers to the risks and they
            are simply responsible.
          • @ honeymonster

            It's not just OSS that Apple patched. Apple included an Adobe Flash Player fix in their patch and it got counted as a OSX vulnerability as well as a Flash Player vulnerability.


            I have yet to see Microsoft do that. So it seems to be Microsoft that thinks they can get a free ride.
      • Yet More Noise

        Well, where I quoted NeoWin as in "patch arriving soon and good job
        guys", that would have come from:

        The discerning will note that it was, as I described it, a "patch coming
        soon" and not "patch complete and deployed" post.

        I did try to find the thing I remembered reading at ZDNet, not to link
        but to refresh my memory, and I couldn't. I went back just now and
        looked more carefully.

        Do you know how hard it is to find a specific article by googling IE8
        and pwn2own?

        Any way, I found what I think I read. Its source was The Register and
        not ZDNet.

        It ran a day later than I recalled and it does relate the chronology that
        I described, i.e., IE8 release, pwn2own fall, and, day after, turn on of
        security measure.

        Today, following one of its links, I see that this fix stopped a problem
        discovered at the BlackHat conference some 6-7 months prior.
        Another contemporaneous article I just found included speculation
        that had these features been enabled before pwn2own, then Nils'
        exploit would not have worked. This is strictly the author's
        speculation and I may have given it more credence than it deserved.

        I am also reminded, via another Talkback today, that though Vista was
        a step up from XP's security, a lot of people are still using XP.

        So I'm pretty much convinced that Nils' exploit remains unpatched and
        a concern.
  • The part of this article that makes my eyes roll the most

    "Microsoft is yet to fix the vulnerability"

    go figure...
  • But OSX has worse security...

    ... because they find and fix more vulnerabilities than Microsoft. (rolls eyes)

    LOL @ [i]"Microsoft is yet to fix the vulnerability"[/i]
  • What is truly interesting

    is the fact that the Safari bug was really a webkit bug and that Google Chrome was also vulnerable.

    1) Unlike Safari, Chrome actually features a sandbox for the browser process. So even though Chrome experienced the same bug it was far less grave in Chrome.

    2) Apple and Google coordinated the patching of the bug. If Google had patched this bug before Apple, they could have given away the recipe for exploiting Safari and leaving OSX users hanging out there.

    This latter point highlights a <b>big</b> problem for Apple (and OSX users by extension) going forward. Much of the software bundled with OSX is actually open source. If you look over the latest monster patch for OSX you will find that a good number of the vulnerabilities had been patched months ago in other products from other vendors using the same libraries.

    Would-be attackers could have looked at the patches for - say Ubuntu - and checked to see if OSX was vulnerable. And it would have been. The fact that Apple patched some of these vulns 3 months after other vendors gives attackers 3 months to exploit them on OSX.

    Either Apple will need to coordinate closely with <i>all other vendors</i> using the same libraries - like what they did with Google in this case - or they will have to scale down their reliance on those shared products.

    The first option will often conflict with other concerns of Apple, especially a desire to properly test and ensure compatibility with the OSX stack.

    If Apple rush in patches, other products in the OSX ecosystem may break, leading to customer dissatisfaction. If Apple takes time to test against popular products/features of OSX and it ecosystem they may inadverdently leave their customers highly vulnerable (with exploit recipes in the wild).

    Their only option seems to be tight coordination. But given the many different sources and different agendas that may very well turn into a nightmare.

  • RE: Apple eliminates CanSecWest Pwn2Own flaws

    Great!!! thanks for sharing this information to us!
    <a href="">seslisohbet</a> <a href="">seslichat</a>