DISQUS

Yuda · 2 years ago

Are PPC Macs vulnerable as well, or just MacIntels?

Thomas Ptacek · 2 years ago

PPC hasn't been confirmed vulnerable yet. You are dependent on the 3Com Zero Day Initiative to "clear" details like that for distribution, and I don't like it any more than you do.

Rosyna · 2 years ago

So the bug is in QuickTime for Java? or is it in Java itself?

Thomas Ptacek · 2 years ago

QuickTime. Think of it as a problem that can be triggered only if Java is enabled.

Drew Thaler · 2 years ago

Based on the statements so far it sounds like the vuln uses QT4J to call into the platform's native QT APIs, where it triggers a bug of some sort. (Bad data, buffer overflow, etc.) That would mean QT4J is just the vector, and doing its job by passing the call through -- it's necessary to trigger the bug, but not at fault.

That would explain why disabling Java will block the vuln, and also why it should readily affect other OSes.

Ryan Russell · 2 years ago

So, if you guys are presumably not supposed to be leaking this information you've sold to 3com, what are the sources?

Thomas Ptacek · 2 years ago

3Com clears the information piecemeal.

tom ferris · 2 years ago

nice.. ;)

John Herron · 2 years ago

Wow, effectively its cross-platform. If the bug exploits a built-in OS interface feature then the current attack may work as-is against a Windows based computer. But I assume that if its causing a buffer overflow condition that right now its probably DoSing Windows. In which case this may or may not lead to a Windows exploit.

Nice discovery, will certainly keep Apple awake for a few nights.

Giorgio Maone · 2 years ago

Either if it is JS, Java, QuickTime or any other plugin, just another job for NoScript :)

http://noscript.net

unclesmrgol · 2 years ago

Is it Java, or Javascript?

Thomas Ptacek · 2 years ago

It involves Java, not Javascript.

unclemac · 2 years ago

Is this threat viable for all level of users? If a machine is being run from a managed (non-admin) account can the code still be executed and access gained?

Thanks for the info!

Thomas Ptacek · 2 years ago

Yes. Yes.

John Herron · 2 years ago

1) I think some people are confused by the suggestion to use NoScript to mitigate this risk. The Quicktime vulnerability involves 'Java' (passed to it by the browser). NoScript can be set to stop JavaScript, Java, and browser plugins on a (allow/deny) site by site basis. The new version also has some protection for XSS. If you use Firefox it is a must have layer of protection.

2) Still waiting for information as to whether this vuln takes advantage of a poorly thought out built-in Quicktime function or executes after a buffer overflow. This information greatly affects how this affects Windows. This info is probably still embargoed.

Mike Davis · 2 years ago

It is my understanding that this exploit only gains the privilage level of the user running the browser (not full root access, otherwise the other prize would have been claimed as well). If this is the case, then it should be possible to create a "sandbox" account on the Mac where only the Safari Application can be run, and only the "sandbox" user's directory can be written to. This should be able to restrict the damage that this potential exploit can do to this specific account. This might be an acceptable work around (when combined with fast user switching) for those that need java for the sites they are using. Ideas?

Thomas Ptacek · 2 years ago

Mike, you could do that. Nobody else does it. More importantly, as funny as it is to point out how bad this vulnerability is, and how ironic it is, it doesn't really put anyone at risk (until Rosyna from Unsanity reverses it entirely from the trickle of information 3Com is letting out).

So I recommend doing, uh, nothing.

Billy · 2 years ago

I really do not belive this at all. I have had Macintosh Computers running on the internet serving Websites / Mail / and FTP and they have been running for over two years now and a ton of people Hacking at it and still no one has ever got into them. Wish people like this show us step by step instead of telling that is has happen. Prove it people.

Billy · 2 years ago

I think that is is only a JAVA Issue not a Apple Issue.

Tom Matheson · 2 years ago

But still no access to root, correct?

Thomas Ptacek · 2 years ago

Billy: it's weird that you think that just because you want it to be a Java issue it will be a Java issue. The wishfulness of much of the Mac pundit community is pretty fascinating. It's not a Java issue; it's a vulnerability in Apple's QuickTime code. Java is just the vector that exposes it.

Tom: on the overwhelming majority of deployed Macs, breaking Safari puts you one move away from checkmate --- "admin" users are root-equivalent.

But who cares? Read this:

http://www.matasano.com/log/809/a-little-challe...

Especially the comments.

Worrying about "root" on a single-user machine is like worrying about a bank robber stealing the doors and the chairs.

Dave · 2 years ago

Has this been reported directly to Apple? If so, please provide a reference.

If this hasn't been reported to Apple, this notice is dubious at best. To release a notice about a vulnerability and not report it to the accountable parties is irresponsible rumor-mongering. I would hope this isn't the kind of thing matasano is participating in.

Billy · 2 years ago

Thomas: It is not Weird that I think Java is at fault, I know that Java is a tool that allow control over alot of things both on the Macintosh and on the Windows Computers as well. Maybe there might be a hole in Quicktime that Java the Transport used. Also to answer your quote to Tom: “admin” users are root-equivalent. Only a real Administrator like me and others Know not to set users to have ADMIN privileges. I still would like to be show. Talk is nothing but talk until it can be proven. We hear about exploits all of the time, most of us would like to see the proof. Most users like myself are security aware of problems and I myself would like to see the proof. At least I don't have users called test of admin or even root on my computers. You can hack at those accounts all day and never get in.

Thomas Ptacek · 2 years ago

Billy, what's weird is that you clearly have no information about what the details of the exploit are, but you're speaking with some authority about what those details are. You've made your point; if you have another point to make, go ahead. I'm going to delete any comments that suggest "facts" about the vulnerability that I know to be false.

David Schor · 2 years ago

PowerBook user here still waiting to hear if this is an intel-only issue. It seems to me the Apple PowerPC based machines have significant security advantages over both MacIntels and Windows machines, for obvious reasons.

PPC forever (or at least until the warranty runs out).

JohnGruberIsARobot · 2 years ago

Thomas:
Oh ye of infinite patience.

J.M. · 2 years ago

If only people read this at face value.

If this was a Java vulnerability, then it would be a Java bug, not a Quicktime bug. This would put Linux, *BSD, etc. at risk as well. But this is not just a drive-by download via Java (haven't heard of any drive-by downloading via Java, except if malware is already installed), it's Quicktime's handling of it.

Just for future reference people, if "Java" is said, then take it as Java, not "Javascript," they are two totally different things.

Anomalyous · 2 years ago

- Disabling Java stops the vulnerability.

Uninstalling Quicktime seems to stop the vulnerability as well. ;)

Richard · 2 years ago

I,m a home PC user and use WIndows 98 SE on an
AMD 1800 XP (like a Pent 4) and have QuickTime 6.4

The Apple site said I can't upgrade/Patch unless
I have an NT type O/S.

What are my options, Please?

Regards, Richard dickie@pobox.com

ps how to disable Java, if that's what I must do or
uninstal QuickTime? What about those 3rd party programs with Codecs packages that esentially compete with QT & Real player?? rrrr