mike, You have some good points. I went back and did some research. I will start with my own summary and add some references at the end.
1. At CanSecWest, they started with a MacBook connected to an open Wi-Fi network, but nobody could get through. Nothing was done to the MacBook but install the OS and run an Update to get the latest patches. [Side note - with a Windows box in the same condition, it would have only taken a few minutes to get through.] 2. The relaxed rules allowed a contestant to send in a URL, and a contest organizer would enter that URL in Safari (go to the web page). This resulted in a vulnerability being exploited. Indeed, the user had to do nothing but click on a URL to load a web page. So they awarded the MacBook to Shane as CNET reported. 3. The exploit was incredibly tricky and took a full 9 hours to get working. It was not a Safari vulnerability as the CNET News.com article indicated. It was a vulnerability in a QuickTime for Java library routine ( QtJava.dll) [side note, I find it difficult to believe that Mac OS X or Safari actually executes DLL files - but any dynamically linked library would qualify in my book, as the concept is the same] see http://www.matasano.com/log/812/breaking-macbook-vuln-in-quicktime-affects-win32-apple-code/ for some details and discussion. see http://www.zerodayinitiative.com/advisories/ZDI-07-023.html for a crisp notice of the vulnerability 4. From what I can glean from these two sites and a bunch of others I went through (very few have any actually useful facts), the web page loaded some malformed QuickTime, which exploited the QuickTime Java library's insufficient input checking to then do a buffer overflow and execute code on the MacBook. The scary side was that it wasn't a Safari problem as first noted, but impacted QuickTime on Windows and Mac. You QuickTime users on Windows should remember having to upgrade this past Spring. [side note: I still have two Windows machines at home my family insists on - the rest are all Linux] 5. What was not fully pointed out, and what is difficult to explain in layman's terms, is that this was a zero-day exploit. Essentially, that means that Dino A. Dai Zovi found a bug that no one else had known about and exploited it. 6. Those who want to make fun of Mac zealots can read the first Matasano blog entry on this (I cited a follow up with details in it above): http://www.matasano.com/log/806/hot-off-the-matasano-sms-queue-cansec-macbook-challenge-won/ Summary: CNET News.com was off base, but in their defense, no details were actually being released, so they had to guess. My summary at the bottom here was off base, similar to CNET News.com, in that it was roughly correct but misleading. The code downloaded by the user was embedded in malformed QuickTime that was automatically executed by the browser. So it wasn't like the user intentionally downloaded code and then ran it, which is what my statement implied. On 10/19/07, mike <[EMAIL PROTECTED]> wrote: > > Not true. From Cnet. > > The successful attack on the second and final day of the contest required > a > conference organizer to surf to a malicious Web site using Safari on the > MacBook--a type of attack familiar to Windows users. > > Nothing was downloaded to the machine and run, indeed this exact attack is > probably the most common attack on windows...and apparently not hard to > exploit on a mac. > > Full article: > > http://www.news.com/2100-7349_3-6178131.html?part=rss&tag=2547-1_3-0-5&subj=news > > On 10/19/07, John DeCarlo <[EMAIL PROTECTED]> wrote: > > > > > > 3. The incident you cite was one where a reward was given to anyone who > > could exploit a Mac - no one could for the $10,000 offered. So they > then > > changed the rules so that you could have a user download anything they > > wanted to the machine and then run it. Under those new rules, someone > > exploited QuickTime. I agree with you that any system can be exploited > if > > you have a user download something and then execute it with sufficient > > privileges. > > > > > > > ************************************************************************ > * ==> QUICK LIST-COMMAND REFERENCE - Put the following commands in <== > * ==> the body of an email & send 'em to: [EMAIL PROTECTED] <== > * Join the list: SUBSCRIBE COMPUTERGUYS-L Your Name > * Too much mail? Try Daily Digests command: SET COMPUTERGUYS-L DIGEST > * Tired of the List? Unsubscribe command: SIGNOFF COMPUTERGUYS-L > * New address? From OLD address send: CHANGE COMPUTERGUYS-L YourNewAddress > * Need more help? Send mail to: [EMAIL PROTECTED] > ************************************************************************ > * List archive at www.mail-archive.com/computerguys-l@listserv.aol.com/ > * RSS at www.mail-archive.com/computerguys-l@listserv.aol.com/maillist.xml > * Messages bearing the header "X-No-Archive: yes" will not be archived > ************************************************************************ > -- John DeCarlo, My Views Are My Own ************************************************************************ * ==> QUICK LIST-COMMAND REFERENCE - Put the following commands in <== * ==> the body of an email & send 'em to: [EMAIL PROTECTED] <== * Join the list: SUBSCRIBE COMPUTERGUYS-L Your Name * Too much mail? Try Daily Digests command: SET COMPUTERGUYS-L DIGEST * Tired of the List? Unsubscribe command: SIGNOFF COMPUTERGUYS-L * New address? From OLD address send: CHANGE COMPUTERGUYS-L YourNewAddress * Need more help? Send mail to: [EMAIL PROTECTED] ************************************************************************ * List archive at www.mail-archive.com/computerguys-l@listserv.aol.com/ * RSS at www.mail-archive.com/computerguys-l@listserv.aol.com/maillist.xml * Messages bearing the header "X-No-Archive: yes" will not be archived ************************************************************************
