BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7
This just in: anonymous sources at 3Com confirm Dino’s QuickTime vulnerability is exploitable in IE7 and IE6 on Windows XP.
Watch this space for details (Is XPSP2+DEP reliably exploitable? You can’t run IE7 on XPSP1 —- so, probably! Vista?) as they’re made available to us.
I think we can now safely conclude: this is a hell of a finding. Way to go, Dino!
Irony Alert
Consider the possibility that the one platform this vulnerability won’t work against is Windows Vista.
[Update: 4/25]
As usual, the comments on this post are much more valuable than anything I’ve written. Rosyna Keller and Skywing are discussing the protection mechanisms in IE6/IE7 (anyone know what the equivalent protections are in Safari? Oh, wait…).
More importantly, our source at 3Com has re-confirmed that IE6 and IE7 are vulnerable to this attack. More details about the vulnerability as they become available.
[Update: 4/27]
I’m simply deleting comments that say things like “XXX is not vulnerable” or “YYY is vulnerable” without evidence.
32 Comments so far
Leave a reply
DEP is only really useful if the hardware supports the NX bit (Windows XP tries a software approach). Also, DEP is off by default in IE on XP (just IE) due to problems with some ActiveX plugins (most of which, such as the Adobe ones, seem to have been fixed by now). You have to turn it on separately in the advanced prefs in IE.
And for Vista, the Protection Mode in IE is disabled if UAC is disabled. For some odd reason, the two are tightly connected. So for anyone that disabled UAC on Vista…
(I’m sure the connection makes sense to the implementors, but if I was the lead, I would have gone through hoops to make sure they weren’t too dependent).
Terri Forslof, manager of security response at TippingPoint, confirmed with me today that any Java-enabled browser is potentially vulnerable. Internet Explorer is not, she said, given its sandbox feature, which “does handle the vulnerability appropriately,” she said. A sandbox is an area in memory outside of which a program cannot make calls.
You mean, IE7 on Vista?
@Ptacek:
Internet Explorer 6 and 7 are not affected because they handle the vulnerability appropriately.
That’s the opposite of what 3Com told me.
Also, IE6 doesn’t have a “sandbox” feature.
“this”, it’s called Protected Mode…
http://blogs.msdn.com/ie/archive/2007/04/04/protected-mode-for-ie7-in-windows-vista-is-it-on-or-off.aspx
And as I said, it’s off if UAC is off and as I implied, it’s for Vista only.
Also, as I said, DEP is off in IE7 on XP and Vista by default. And from the comments, it seems that DEP doesn’t play well with Java. How amusing given the current problem.
http://blogs.msdn.com/michael_howard/archive/2006/12/12/update-on-internet-explorer-7-dep-and-adobe-software.aspx
Sandbox is the java sandbox implemented in Internet Explorer 6 and 7. It’s not the protected mode!!!
“Sandbox is the java sandbox implemented in Internet Explorer 6 and 7.”
I can’t seem to understand this statement. Neither IE6 nor IE7 ship with a JVM. So a Java sandbox couldn’t be implemented *in* them. IE7 implements Protected Mode on Vista (if UAC is on, which is the default). Everyone but Microsoft would refer to what Protected Mode implements as a “sandbox”. Perhaps MS went with a different term due to the association the word “sandbox” has with urine and hidden fecal matter.
Sun explicitly refers to Protected Mode as a “sandbox” in their release notes http://java.sun.com/javase/6/webnotes/#windowsvista and they explicitly call out the fact an applet on XP can do whatever it wants.
You are all correct:
Initial testing of Dino’s POC showed IE versions *not* to be vulnerable.
After some slight modifications to the code, we were able to get the code working for IE6 and IE7 on XP.
We are still testing on Vista at this time.
This is just what happens when the news coverage is faster than the investigation itself- more details unfold themselves over the course of a few days, and through further testing new things are learned.
Remember, last Friday this was a vulnerability in Safari?
We’ll do our best to keep you folks updated here if anything changes regarding the details of the vulnerability itself.
Thomas: As others have pointed out, DEP is by default turned off for IE. You can override this by removing the opt-in/opt-out option and setting the appropriate boot.ini/bcdsettings to force DEP to always on. Unless you have a good reason to not do this, I would recommend doing so anyway (forcing NX support enabled with the boot parameter), as it is possible (though convoluted) to disable NX on-the-fly for the current process, from the context of certain exploit scenarios with a ret2libc style attack[1].
Rosyna: The reason why UAC and Protected Mode appear to be interconnected is that they are both based on the token integrity level mechanism. To put it simply, token integrity levels are a sort of additional type of kernel-supported access control (checked before conventional ACEs in an ACL), where objects with a security descriptor can be marked as requiring a certain minimum integrity level to perform certain operations (e.g. read, write, execute).
Barring any implementation bugs, the system does provide some limited real value, even if it somewhat of a hack. How it works in protected mode is that your IE process runs with a “low” integrity level (the defaults for everything being “medium”). By default, all securable objects contain an ACL that denies write to low integrity callers (except for a couple of specially reserved locations under the userprofile tree, such as %userprofile%\AppData\LocalLow). There are similar restrictions against writing to HKCU or HKLM; in practice, the default configuration locks out low integrity processes from writing outside of the HKCU\Software\AppDataLow key.
In essence, integrity levels are a sort of bolt-on addition to the NT security model that allows you to partition a user into different trust levels, with lower trust level instances of a user (e.g. low integrity) being prevented from stomping on higher trust level instances of the same user.
Now, this system isn’t perfect. You’ll note, for instance, that I said that by default low integrity processes can’t *write* to but a few restricted locations; they can still *read* (in the default configuration) from any location that the ACL would allow the user SID to access. This means, for example, that a compromised IE protected mode process could still be used to, say, steal your top secret personal documents, if they were created under the same user and used the default security descriptor. A compromised IE protected mode process could *not* be used to do things like overwrite those documents, though, or to drop code in locations where it might be run automagically (since there are only a handful of directories a low integrity process can write to by default, after which the process would have to convince the user to go out of his or her way to run a program dropped in such a location). Because these restrictions are enforced by the kernel, they are ostensibly maintainable as secure (again, barring implementation bugs or design oversights).
[1] http://www.uninformed.org/?v=2&a=4&t=sumry
@Rosyna
In IE6 and IE7 the Plug-ins run in a sandbox.
sandbox is the memory location where the code is running, it’s NOT the IE7’s protected mode
First I wanted to commend y’all for a great site / blog. Very informative, and I’m glad to get past the religious OS flame wars. I have been lurking for a while and have a stupid newbie question.
What does Matasano Chargen mean? Where did that name come from?
I looked at the about pages, wiki, faq, etc. and couldn’t find the answer. I know I am a geek and stupid stuff like this bothers me.
Then again, they say the only stupid Q is the one not asked.
Thanks,
Hash
Matasano is the name of our company. We chose it from a list of names of “exotic” (for Northeasterners) fruits and vegetables. It happens to sort of mean “bad apple”, which we also like.
Our friend Ivan Arce from CORE informed us shortly after we chose the name that it also means “quack doctor” in South America. “Killer of the healthy”. So we like the name even more now.
“Chargen” comes from the name of my previous personal blog. It’s a service you can connect to on old Unix boxes to get a stream of gibberish, which you can use to test your ability to read gibberish from random hosts. It seemed like an apt metaphor for blogging.
“this”: no offense, but 3Com has now confirmed (twice more) that this vulnerability affects both IE6 and IE7 on WinXPSP2. I’m enjoying reading discussions about sandboxing/protection technologies in IE, so, by all means continue — however, I’m going to delete comments that assert, by some semantic argument about “sandboxing”, that this vulnerability isn’t present on IE.
[…] Mais detalhes no artigo completo do Matasano Chargen. […]
“Bad Apple”
ROFL.
Thanks.
Firefox is also vulnerable
I just have a simple question that I’m sure some one can answer. If you visit this apple website.
http://developer.apple.com/documentation/QuickTime/Conceptual/QTScripting_JavaScript/index.html
Read the information in the gray box.
“Starting with QuickTime 7.1.5, you can no longer issue javascript:// URLs or call Javascript functions from within QuickTime movie. This feature was removed from Quicktime for security reasons.”.
The date at the bottom of that page is 3/26/2007. I don’t know when QuickTime 7.1.5 was released. If Quicktime 7.1.5 was installed on the system when Shane Macaulay used the exploit from Dino Dai Zovi. Should that Javascript exploit worked at all?
@mmiller
the flaw in QuickTime + Java, not Javascript.
IE7 in protected mode.
I know this same issue was brought up in previous threads, but even with IE7 in protected mode in Vista, if the exploit could use say a “Pop Up” to invoke the IEInstal.exe (admin broker) process and the user authenticated it via allow/don’t allow, wouldn’t it be “game over” as Thomas often like to say?
On OSX, an install dialog box would require admin password, on Vista wouldn’t it be a spoofed and/or a real UAC dialog box? Not that it makes any difference, but I am thinking of the mindset when the exploit is rendered using click to a web site.
If you “clicked” to go to the website hosting the exploit. Wouldn’t you click on the allow button if the Website politely asked for access?
I really think you should be careful about assuming that user interaction is required to trigger this attack. There’s a zillion ways to get malicious web content in front of a user, and most of them don’t require people to click on links.
Ok, I may be spiltting hairs here, but doesn’t the fact that it is malicious WEB content require some active user interaction? Browser, email, quicktime app. etc. The only passive vector I can think of right now is a dashboard widget or sidebar gadget (or whatever they call those things in Vista) running in the background.
Didn’t the original Mac hack require a user interaction - going to a website? Else it would have been a truly remote exploit. Or has the exploit progressed / gotten nastier?
For starters — and this is just for starters — think about things like XSS.
We have conducted further analysis and here the results:
IE6 an IE7 are not affected
Firefox 2.0.0.3 is vulnerable on Mac/Windows/Linux
I have XP Pro SP2 and IE7. I am going to school online and need java for my classes to work. So, I cannot disable java. What else can I do for protection against this?
On XP Pro, if unable to disable Java, I believe deleting all instances of QTJava.zip and QTJava.jar will suffice.
I mention QTJava.jar because some Java apps appear to copy and/or rename this file to take advantage JRE’s default of adding *.jar files into its classpath.
The best resource for developing or defeating this vuln is
http://lists.apple.com/archives/quicktime-java
That all makes sense, and I’m 99.9% sure you’re right, but remember, until 3Com publishes the details for this, nobody knows for sure whether killing the jars will work.
@COD3R
ROTFL. Do you know what a .jar file is? Do you know what an Applet is? Applet QTJava.jar can be automatically downloaded and executed via Java browser
I’m not paying attention to the jar names we’re tossing around (and I haven’t confirmed anything) but I’m pretty sure you can’t just stick the JNI-driven JDirect code in an Applet.
[…] I was discussing the recent QuickTime bug on Matasano Chargen, and the question of whether it would work in the presence IE7 + Vista and protected mode came up. I figured a more in depth explanation as to just what IE7’s Protected Mode actually does might be in order, hence this posting. […]
Why does IE7 rename .jar files to .zip files when they are download. How can IE7 be configured to download .jar files as .jar files and not as .zip?
This is a real annoyance!