No doubt y'all will read about this sooner or later, and I thought I'd jump in with a few bits of sensibility, considering the amount of mac fanboyism dismissing it for various reasons, many of which aren't relevant.

http://news.com.com/2100-7349_3-6178...-0-5&subj=news

First off, the original requirements to win prizes in this contest was to remotely hack a Mac connected to a network, with no action required on the Mac side. It's true that this didn't happen, so the rules were relaxed.

Now, plenty of Mac people are getting a bit confused there, and claiming this means lots of security was turned off, and the Mac was purposely left more exposed than it would be in reality - and this doesn't seem to be the case. The change in the rules allowed this new exploit to be triggered by browsing to a site with the vulnerable Mac in default configuration (which is what plenty of real world mac users will be using, even if those of us here don't generally use default configs)

While this is less of a problem than some random person finding your mac on a network and jumping straight in to take over it, it's still an issue. Following a link on a forum to a page that contained the exploit is one simple way of getting people to click on it. Sending them an email with a link in it, etc - getting some number of Mac users to click on a link is pretty easy, even if ensuring one specific Mac user clicks on a link isn't necessarily simple.

According to John Gruber at daringfireball.com, It's probably not related to 'Open "Safe" files' in Safari, something that's caused issues before - and that's one of the most common differences between Safari as default, and as configured by many people. Other sites give the impression it's a vulnerability related to Javascript handling.

If so, then *anyone* using Safari is pretty much vulnerable by clicking on a link somewhere. So what are we vulnerable to?

The exploit is reported to give an attacker user-level access via a shell. That means when you theoretically browse to a URL that contains the exploit, through some bug in Safari the exploit is capable of running shell (terminal) commands on your Mac as your user.

While that's not root level access (full ability over the machine), it's still enough privileges to, for example, delete everything important to you in your user folder, script your email app to tell your boss to go to hell, tell your machine to download another app from somewhere, run it in the background, set it as a login item for your user, and have it constantly working away in the background doing work for the attacker. Whether that's as a spam relay or what, is entirely up to the attacker. User level shells can still do a lot, even if they can't do *everything*.

Another thing they can do is run code to gain root access via a separate vulnerability if it exists somewhere, that may otherwise be inaccessible to someone outside your network.

I'm quite interested in OS X exploits, so I'll be keeping an eye out to find info on how it works & what's needed to trigger it - as that info comes in I'll try to post it in this thread without the hype, and without the overdone apple defence that's already popping up all round the net.

Dana

Dana,

What does your description of 'standard configuration' (and what news.com.com describes as 'all Security Updates, but no additional security or settings) actually mean?

There are many of us here for whom security on a Mac means turning on the firewall, opening up the necessary ports, and surfing away. I haven't installed any security software on my Macs for many years, and aside from the firewall and using a non-admin user account, I don't bother myself with it. I'm sure I'm not alone.

A standard config is either an install provided on a machine fresh from Apple, or with a fresh new install of OSX. The "no additional security or settings" means nobody's gone and turned firewalls on (or off), changed safari's config away from what a fresh install gives, turned internet sharing on, etc.

Certainly your turning on the firewall like you have is one of those additional security measures - it appears it's not one that'll affect this exploit (though as usual - more info will come in about just what affects the exploit and what doesn't).

According to http://www.cansecwest.com/ the machine also had all security updates installed. The contest seems to have started one day before the most recent security update, but won after the security update was released - but none of those updates were for Safari.

Depending how the vulnerability was triggered, it's possible this particular exploit may be Intel only (and if it is, it doesn't preclude the possibility a PowerPC one could be created too)

Dana

I had posted this in "NEWS" but no moderator posted. hmmmmmmmmmm

There's a fair bit of news floating around, but we really need more information.

Arstechnica has a little more technical info. Not much though.

Latest news is that it's a Java exploit. Other browsers using Java are also affected.

http://www.matasano.com/log/806/hot-...challenge-won/

Well that site seem to tell us to turn all Java off in safari in the security tab. Probably not the worst idea if it's only java exploit.

This is turning into a fascinating exploit It appears that not only was a Mac found vulnerable to a pretty simple click-n-run exploit to give an attacker access to your machine via a clicked link on a web page, but it's caused by... Quicktime's Java handling. Not only that, Quicktime may very well open the same vulnerability in Windows. Oh how backwards

http://www.matasano.com/log/812/brea...32-apple-code/

(from daringfireball.com)

More complex than usual...

New details emerging about Dino’s MacBook finding (don’t you just love vulnerability markets?)

Dino’s finding targets Java handling in QuickTime.

Any Java-enabled browser is a viable attack vector, if QuickTime is installed.

Apple’s vulnerable code ships by default on MacOSX (obviously) and is extremely popular on Windows, where this code introduces a third-party vulnerability. (Irony!)

Firefox and Safari are confirmed vectors on MacIntel. Users of both browsers are placed at risk by this vulnerability in Apple’s code.

Firefox is a presumed vector on Win32, if Apple’s QuickTime code is installed. Users of Firefox on Windows are presumed to be at risk because of this vulnerability in Apple’s code.

Disabling Java stops the vulnerability.

of course, disabling java may not be the best solution as some sites still require applets.

im sure apple will put out a fix for this in a timely fashion and the haters will once again be left in the dark

W2ttsy

You can always enable Java if you run across a site that truly needs it.

They will

Let's count down the days until it's fixed. The exploit was created April 20th.

Today is April 24th. For 4 days, those of us with Java turned on are only able to trust that of the hundreds of links we must click on each day, that none of them is going to make a right mess of our machines, by the good grace of those who discovered the exploit and aren't making it public, or if they did, the Mac's relative obscurity.

Dana

I have taken to leaving Java off 24/7... I haven't needed/used it in about 2 years.

A little more info, this time about the discoverer of the vulnerability and creator of the exploit itself, Dino Dai Zovi - he touches on how long it took to find/write what was needed:

http://blogs.zdnet.com/security/?p=176

zdnet also link to another piece with info from Dino, regarding the Quicktime/Java issue:

http://blogs.zdnet.com/security/?p=177

and a link to Dino's page with his previously discovered vulnerabilities in OSX:

http://www.theta44.org/research.html

Dana

And again - another interview with the creator of the exploit, this time by John Gruber himself.

http://daringfireball.net/2007/04/in..._dino_dai_zovi

One of the interview responses related to security that it would do every mac user well to know, given the amazing number of people who call a user-level shell exploit nothing to worry about:

DAI ZOVI: A remote root exploit is typically much harder to come by than a remote user privilege exploit. However, in general, local user to root exploits are simpler to find than remote user-privilege exploits. So, in general, it is reasonable to assume that once an attacker has local user access to a system, root is not difficult to obtain. One should also point out, that if the user privileges are an admin user, it is possible to write to /Applications/ and /Library/, and this access is quite damaging. On a (primarily) single-user machine like a laptop or desktop, even non-admin user-level privileges are enough for most attacks (reading data, corrupting running applications, etc).

Dana

What about this Q? There's the usual talk that you should run as a non admin user for extra security, but you still need to have an admin account set up so that your non admin account can function.
So if an attacker gained access to your non admin user account, surely accessing the admin account, and then onto root would not be that hard, considering admin to root is...
Is there really much advantage to running a non admin account, except that the attacker may only get to the non admin user level and then get stuck?
I mean Dai Zovi claims to only run as a non admin.... should we be taking this precaution more seriously regardless of the probability of being attacked? I have never run less than admin except for new accounts for my kids etc.