But if you read further down in the interview you linked to, Dino Dai Zovi is quoted as saying
http://blogs.zdnet.com/security/?p=176

But still it's all speculation at this stage. I personally will be erring on the side of caution.

Yes, I saw that but after saying what he already had, it seems like he was trying to minimize the user's actions to make the hack appear to be more than it was, which was enough to win the contest within its rules, but probably not much more.

I'd like to see this hack tested by sending the link to a computer not touched by anyone trying to hack it. An impartial 'judge' would click the link and do no more. If it works under those circumstances, then I'd believe it.

It is clearly stated that the contest is only open to attendees of the conference. What I am guessing that means is that the Mac in question was not accessible via the wide Internet but was only accessible via the local area network of the conference. Hence the malicious web site was running on one of the attendees machines that was physically present at the conference. So what Shane needed to do was to set up the web site and perhaps to manually react when the web site was visited. Shane did not need to do anything on the Mac in question - all that was required was that the organizers visited the supplied URL on that Mac.

In all honesty it is not that unbelievable, the sole purpose of a web browser is to send and receive requests over the internet/network. If this exploit was done through java and the browser had java enabled, and all that was needed was a visit, then boom your rooted/infected/whatever seems possible to me.

I mean how does safari initially react to java applets, scripts, and the like when hitting a web page?

By itself it is very believable. In the context of a contest that was set up from the begining to find a winner by relaxing the rules over the course of the contest, it's suspect. Just how much did they relax the rules? Nobody seems to know, which makes me more suspicious.

You think... $10,000 for a gag... something Mac users will simply laugh at later?
Sounds like a stretch. How do you figure that one? [explain]


Do you know anything about shell scripts?

Do you actually believe there's something a human can do (in this context)
that a script can't do a *million* times faster. What could that be I wonder?
I don't see what more anyone here can say that hasn't been said already.

Anyway, I saw reference to a line saying the objective was to get a "shell".

So the person doing the typing was playing the hacker's role, typing as he
wreaked havoc on the remote Mac. (I already said as much... but it seems
you conveniently ignored that explanation). How do we know YOU'RE real?

:p

As I pointed out above, this whole affair has been very badly reported. And cwtnospam has been confused by the reporting about what Shane did.

Here's what happened as far as I can piece it together.
There are two machines on a local wireless network:
Machine A is the Mac that is the target of the attack. Machine A is in the possession of the conference organizers and is not physically accessible to anyone else.
Machine B is some other arbitrary machine that Shane Macaulay has in his possession. (There is no requirement that this machine is a Mac.)

Dino Dai Zovi communicated his idea for the exploit to Shane Macaulay. He gave step by step instructions to Shane on how to set up the malicious web site on Machine B and then what to do once the attack was triggered (via the specified URL).

Shane told the organizers the URL for the malicious web site and the organizers used Safari on Machine A to go to that URL.
This provided shell access on Machine A to Shane who was on Machine B.

www.securityfocus.com/archive/142/464216/30/0/threaded

There's the 'progressive' rules part.
[move up to read the whole thread]

I don't know anything about the shell he connected to, or even if he connected to it without first physically accessing the test computer, so I don't know what could be accomplished in it. I do believe that there are many things a user with physical access to the computer might be able to do that the shell might not.

Once again, I'm not saying that he didn't succeed according to the rules of the contest. I'd just like to know exactly how far those rules were relaxed. I guess I trust this Dino guy more than I do the organizers of the event, who are after all part of the same 'security' industry that's been doing everything it can to scare Mac users into using AV software for years.

Hmmm, I must have been typing my previous post while you were posting this one. I guess that answers my question then.

As long as we got this far, there are a pair of articles at roughlydrafted,
one at arstechnica, two (so far) at rixstep... one of which leads to these:

http://security-protocols.com/sp-x45-advisory.php
http://security-protocols.com/sp-x46-advisory.php

Apparently two flaws reported by one Tom Ferris, first one over a year old.

[Not sure they're what was used the other day, but it seems to be implied]

--

Admittedly: it's not too likely anyone will actually run across an
example of this... and (by itself!) root was never attained... and
(by itself!) it contains no worm characteristics... so we don't need
any tin foil hats.

But neither should we take away from it that which it does deserve.

At this point, it must get patched... or it would be the the beginning
of much bigger headaches. No doubt.

Check your "Software Update" - "Security Update 2007-004 v1.1" and "QuickTime 7.6.1" are up...

Edit:
Just to clarify, the QuickTime update addresses the vulnerability that is the topic of this thread.
The security update is for something else.

so I am confused still, so the media just basically reported this it a totally FUBAR'd way?

So, did the guy really get the 10,000 dollars (haha reminds me of the simpsons when they had that film festival!)??????

Well, one consequence of the QuickTime update appears to be killing a class of animated ads, including the ones we display here. They must have depended on some QTforJava 'feature' that was changed in closing the security hole. Or maybe the Flash plugin used it?

They must not be in the audible.com ad, because I see the animation in that.

All I see is the QuickTime logo with a question mark through it. The Apple site, by comparison, behaves normally.

This is in Safari, by the way. I have not tried other browsers yet.

Have you changed your Quicktime settings? Maybe turned off Java? I'm using Safari, I've applied the patch, and I see the ad.

Hadn't changed them lately, but I fixed this display problem by going into the QuickTime prefpanel and under Advanced->Mime Settings->Miscellaneous telling QuickTime to not handle Flash media. I must have set that at some point. Now, all is back to normal.