-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/839/the-bug-report-that-would-not-die-dinos-finding-works-in-ie7/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
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).
Internet Explorer 6 and 7 are not affected because they handle the vulnerability appropriately.
http://blogs.msdn.com/ie/archive/2007/04/04/pro...
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/20...
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/#windowsv... and they explicitly call out the fact an applet on XP can do whatever it wants.
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.
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
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
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
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.
ROFL.
Thanks.
http://developer.apple.com/documentation/QuickT...
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?
the flaw in QuickTime + Java, not Javascript.
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?
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?
IE6 an IE7 are not affected
Firefox 2.0.0.3 is vulnerable on Mac/Windows/Linux
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
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
This is a real annoyance!