Matasano Chargen - Latest Comments in BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Peter — Tue, 19 Jun 2007 09:09:06 -0000

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!

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Thomas Ptacek — Sun, 29 Apr 2007 14:13:02 -0000

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.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

kull — Sun, 29 Apr 2007 05:41:13 -0000

@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

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Thomas Ptacek — Fri, 27 Apr 2007 16:08:24 -0000

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.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

C0D3R — Fri, 27 Apr 2007 16:02:39 -0000

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

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Dixie Scott — Thu, 26 Apr 2007 18:43:15 -0000

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?

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Fake Terri Forslof — Thu, 26 Apr 2007 09:33:10 -0000

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

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Thomas Ptacek — Thu, 26 Apr 2007 00:37:04 -0000

For starters --- and this is just for starters --- think about things like XSS.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Hash — Wed, 25 Apr 2007 21:15:47 -0000

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?

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Thomas Ptacek — Wed, 25 Apr 2007 17:08:04 -0000

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.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Hash — Wed, 25 Apr 2007 16:24:52 -0000

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?

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

carl — Wed, 25 Apr 2007 14:57:47 -0000

@mmiller
the flaw in QuickTime + Java, not Javascript.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

mmiller — Wed, 25 Apr 2007 14:18:37 -0000

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/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?

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

luc — Wed, 25 Apr 2007 13:28:25 -0000

Firefox is also vulnerable

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Hash — Wed, 25 Apr 2007 13:26:38 -0000

"Bad Apple"

ROFL.

Thanks.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Thomas Ptacek — Wed, 25 Apr 2007 12:59:13 -0000

"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.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Thomas Ptacek — Wed, 25 Apr 2007 12:52:57 -0000

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.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Hash — Wed, 25 Apr 2007 12:50:27 -0000

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

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

this — Wed, 25 Apr 2007 11:50:21 -0000

@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

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Skywing — Wed, 25 Apr 2007 11:25:08 -0000

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

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Terri Forslof — Wed, 25 Apr 2007 11:01:37 -0000

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.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Rosyna — Wed, 25 Apr 2007 10:48:09 -0000

"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/#windowsv... and they explicitly call out the fact an applet on XP can do whatever it wants.

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

this — Wed, 25 Apr 2007 10:09:08 -0000

Sandbox is the java sandbox implemented in Internet Explorer 6 and 7. It's not the protected mode!!!

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Rosyna — Wed, 25 Apr 2007 09:31:54 -0000

"this", it's called Protected Mode...

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...

Re: BREAKING: The Bug Report That Would Not Die: Dino’s Finding Works In IE7

Thomas Ptacek — Wed, 25 Apr 2007 09:06:04 -0000

Also, IE6 doesn't have a "sandbox" feature.