The Active Network
ActiveMac Anonymous | Create a User | Reviews | News | Forums | Advertise  
 

  *  

  Secunia: Internet Explorer 7 "mhtml:" Redirection Information Disclosure
Time: 12:25 EST/17:25 GMT | News Source: ActiveWin.com | Posted By: Robert Stein

A vulnerability has been discovered in Internet Explorer, which can be exploited by malicious people to disclose potentially sensitive information. The vulnerability is caused due to an error in the handling of redirections for URLs with the "mhtml:" URI handler. This can be exploited to access documents served from another web site.

Write Comment
Return to News

  Displaying 1 through 25 of 327
Last | Next
  The time now is 5:56:40 AM ET.
Any comment problems? E-mail us
#1 By 52115 (66.181.69.250) at 10/19/2006 1:27:27 PM
And Vista is going to be any better? This is integrated into Vista and this failed.. Makes me feel all warm and fuzzy.. Like that feeling of: "Oh !(*&#(*&^$! That's not good.."

#2 By 23275 (68.17.42.38) at 10/19/2006 1:32:44 PM
#1, This one is a very minor hold-over from IE 6. They carried the warning over largely for effect and not many people on the scientific side of CS, regard this one as valid - neither does Microsoft - and given the number of patches they do release, they'd have addressed it if it were an issue BEFORE IE 7 went gold.

Again, this one was carried for effect and should not have been posted here - not as I assess it, in any case.

BTW, Vista's design and IE 7 with PM [on by default], would defeat exploits based upon the wild set of behaviors needed to take advantage of this lowest level alleged vuln.

#3 By 15406 (216.191.227.68) at 10/19/2006 1:38:51 PM
#2: Have you supplanted parkkker as the forum's official MS Apologist?? A bug was reported in IE6 6 months ago. Not only wasn't it addressed, but it made its way into IE7. It may not be an earth-shattering bug, but it shows how much IE6 cruft is lurking in IE7. Next week's bug should be even better. And the same day, MS announces that XP SP3 will come around in 2008, 4 years after SP2. Amazing, isn't it?

#4 By 23275 (68.17.42.38) at 10/19/2006 2:39:07 PM
#3, C'mon, fella... let's just stick with some facts and a little science - first, yeah, there is a default IE 7 mode that uses a lot of code form IE 6 - it has to... to support web developers that leveraged IE's engine - that's the default mode for now. IE 7, supported by the proper DOCTYPE TAGS shifts to its new and desired mode - which by the way, has the greatest support for new and emerging standards based web technologies. So, in effect, IE 7 is vastly more capable and sophisticated under the hood than any other browser.

Once dev update sites/apps, they can easily [like two seconds], add TAGS to tell IE 7 users to use the more advanced engine. It's that simple, and if you actually cared about the folks that use this site to keep up with what is REALLY going on, you'd learn things like this and share them rather than continuing to spew venom. I mean, at least chrishedlund is funny - you're just silly.

Regardless, thanks for the opportunity to introduce one more example of why IE 7 is truly "innovative" and a decent browser that does reflect Microsoft's and the IE dev team's care for both users and devs.

Next time, please make it a little harder to flush what you say - I'm getting bored.

#5 By 15406 (216.191.227.68) at 10/19/2006 2:59:58 PM
#4: I'm getting dizzy from your spinning. I'm aware of compatibility mode (or lock-in victim mode depending on your POV), but that didn't mean they should have tried a little harder to fix the known issues that they decided to migrate to the *new* browser. You say IE7 has the greatest support for this & that which makes it vastly more capable. Sources? You sound like the IE7 marketing brochure. In every review I've read, it's the same: IE7 looks nice but is playing catch-up with Firefox and Opera.

And why should web devs have to yet again add more custom IE stuff to their pages just to cater to MS' lack of standards compliance - no matter how easy it might be? IE-only websites are so 1990's.

I didn't see anything in your posts that describes how IE7 is so innovative. All I see is you polishing the MS behind with vigour like you do in every post I've read for the last week or two. If you're bored, get a dog.


#6 By 61 (71.251.77.56) at 10/19/2006 3:01:35 PM
Regardless, this doesn't effect Vista at all.

#7 By 7754 (216.160.8.41) at 10/19/2006 4:04:14 PM
#1 (and others)--a few things:

1. This is not a remote-exploit or DOS vulnerability; it's a disclosure vulnerability.

2. According to Bink.nu, it's not an IE 7 vulnerability, it's technically an Outlook Express vulnerability.

3. It doesn't affect Vista.

#8 By 23275 (68.17.42.38) at 10/19/2006 4:20:16 PM
#5, OK - one last one on this. The cursory editorial reviews are inaccurate and canted to the left of scientific fact. So use them and link them all you wish - they matter very little.

As to why IE 7 is truly innovative - you could begin with how it works in XP SP2 - and how the shell is actually modified very little - no small achievement on its own - bringing Vista generation code back into XP SP2. How IE 7 executes - within its own space is pretty impressive, with the Kernel being modified largely to support an entirely new RSS engine that is very unqiue to any browser's native capabilities.

We could move onto the stack - skipping hundreds of other considerations along the way - where, like a modified W2K3 SP1 server, packet frame sizing is supported for the first time in XP SP2 - massively cool and important as network and connection speeds continue to climb upward - this feature is very dynamic and adjusts on the fly - very cool. We could also talk about the broker agent and how it manages what type of code can be executed not in, but around IE 7 - huge hint there to encourage folks ot explore how this makes malicous code authors' jobs so much harder.

As to linking to other Internet sources for validation - nope. Won't do that very often - I prefer to find out for myself, shape my own work and share how we use the technologies to get things done. So the source is my own brain, educated by the many engineers contributing to what we all do. My customers and my team do not follow me because I can link to what others do - they follow in part, because I think, make decisions, and stand behind the results.

#9 By 15406 (216.191.227.68) at 10/19/2006 4:27:25 PM
#7: You type an mhtml: URL into IE6/7 to trigger the flaw. How in the world is this a Lookout Express problem? Last I checked, LE used the IE rendering engine, not the other way around. This is just bogus MS spin to deflect the problem away from their shiny new IE release.

#8: So all the reviews are bogus and only you have the real facts as made up by you. OK, that settles that then.

#10 By 32132 (142.32.208.231) at 10/19/2006 5:15:00 PM
I"ve been looking at the code. What the page does is make a call to this page:

mhtml:http://secunia.com/ie_redir_test_1/? + a random number

Which then calls mhtml:http://secunia.com/ie_redir_test_2 (Which actually loads the Google page)

And then the javascript looks for /new.google/ and dumps the result.

Notice that getting google is hardcoded in the script. I haven't looked the Google news page in this session. The script isn't looking at the pages I've visited.

Can anyone tell me how this can "disclose vulnerable information" in the real world?

This is hardly in the same league as say ... 100 Oracle security holes.

http://www.eweek.com/article2/0,1895,2033143,00.asp

#11 By 2459 (69.22.124.202) at 10/19/2006 5:36:51 PM
#7: You type an mhtml: URL into IE6/7 to trigger the flaw. How in the world is this a Lookout Express problem? Last I checked, LE used the IE rendering engine, not the other way around. This is just bogus MS spin to deflect the problem away from their shiny new IE release.

Outlook Express is the application that contains the code for handling mhtml URLs. IE can render mhtml, but it uses Outlook Express' URL handler.

#12 By 7754 (216.160.8.41) at 10/19/2006 5:53:46 PM
Based on what I've read now, the timing and explanation of this vulnerability disclosure are a little suspect. It doesn't specifically affect IE 7--it affects any version that uses the vulnerable component of Outlook Express... since it is, after all, an Outlook Express vulnerability. Perhaps this is an attempt to "be the first" to find an IE 7 vulnerability? I do appreciate much of what these security researchers do, but some of this has become a total circus. I don't know why it is so common in this field, but many also are quite arrogant and/or petty.

#13 By 23275 (68.17.42.38) at 10/19/2006 6:19:22 PM
#'s 9, 10, 11, and 12 - As I said, it was posted for "effect" to discredit and place IE 7 in a bad light.

#9, Yes, it does and it does not mean that numerous sources are not used - on the contrary, they are and shared as an understanding. I have a personal policy of never saying anything that I have not proven to be factually true at the time. This was born of the realization of the consequences attending careless findings and statements that could have been made when I worked in government. It was something I chose not to do - ever, and I authored the publications used to govern these standards. Sadly, they are very difficult standards to teach and I assess that they were later relaxed. So, yeah, if you read what I offer, you can bet it is supported by a great deal of work and an aggregation of proven facts. If not, you won't see much of a post from me.

#14 By 28801 (68.81.50.122) at 10/19/2006 8:04:35 PM
Thanks Iketchum, that was very informative. Not only did you buttress your argument fully and concisely, but you laid the smack-down on Latch.

#15 By 54556 (71.213.134.160) at 10/19/2006 9:14:39 PM
Perhaps if IE was photographed in blue light ...

#16 By 23275 (68.17.42.38) at 10/19/2006 9:21:05 PM
Then it would look like a silver plate

#17 By 2201 (212.117.228.133) at 10/20/2006 5:53:15 AM
Good work lketchum. You were informative and polite, unlike Latch, who thinks it's funny to call Outlook Express "Lookout Express" like some sniggering n00b teen. It's clear it's an Outlook Express problem, therefore all attempts to make it look like an IE7 problem is like a striker missing an open goal from 3 yards out.

#18 By 54556 (71.213.134.160) at 10/20/2006 7:55:16 AM
yeah, so why didn't you think of that bluvg?

#19 By 15406 (216.191.227.68) at 10/20/2006 10:01:05 AM
#13: You really laid the smackdown on my ass, that's for sure. I have learned though. From now on, I'll spout whatever I want, and if anyone challenges me I'll pull the old "everything I say is a fact and I don't need to cite any sources because everything I say is a fact" club out of the old bag of tricks. Works like a charm for you, apparently.

#20 By 23275 (68.17.42.38) at 10/20/2006 11:17:24 AM
#17, That's the thing about the web that does not work, yet... exchanges between people are more difficult and many people have been conditioned to leave behind, the things they would bring to a conversation between real people. A lot of younger people who grew up with this media tend to hide behind the differences in how it works - BUT they forget, that there is a very small group of people [relatively], that used this type of media for decades before it was in the public.

Latch may be a younger guy and in young people, their passion about this work is expressed differently. It doesn't make it a bad thing and when provided good examples, it tends to keep things more productive and good exchanges can take place.

Chatrooms, IM, email, boards, etc.. - long before the first BBS, some of us were using and building these technologies each day - so the notion that this is new, is not always applicable.
It may have been a lot more primitive in appearance, but it all worked pretty much the same.
The format for man-machine readable messaging - another guy and I wrote a huge part of that in Munich many years ago in a format that pushed it down from strategic systems to nearly all unit types. Think of manually typing out an email header and using a lot of TAGS to encase specific things with less free form text and you'll get the idea.

Things can get mixed up out here when opinion is mixed with fact, or an incomplete understanding is delivered. It get's ugly when it has no need to. I try to type the same way I would speak to people - kindly, and with respect. That is more from simply being old enough to have written a lot of letters - people thought about what they said perhaps more than they do in today's world. When posting, I ensure that what is shared is based upon a lot of work and tests with what the thread is about - my own hands and eyes on the technology and what I've experienced. It takes a lot of time and as the primary research engineer in my company [that is one of my roles and teams], everything has to be in the lab and touched before I'll share an opinion about it. Since we are constantly testing and building new software and systems to integrate into existing platforms, that does provide a good basis for what we hope is real help, or at least a better understanding.

It could be that the sharp, meaningless exchanges are nothing and simply reflect the way things are now, but I hope not and by being nice in a very sincere way, who knows, it could start a trend. I mean we used to really hammer at one another and disagreed all the time about the science, but we never made it personal, or took it personally. When proven wrong, it just made us work harder to get it right. May be that is why my posts are too long for many - it's just too hard to convey any value in a blurb. We'll all work on it.

#21 By 37047 (216.191.227.68) at 10/20/2006 12:43:46 PM
#20 - Very politely put.

However, I disagree that this is really an Outlook Express issue. Since IE uses this particular URL parsing library, then it is an IE issue. Outlook Express may share this issue, but that does not mean that this is not an IE issue too.

If I create a program that uses a few dozen libraries, and security holes are found in my application, what kind of response do you think I'd receive if I kept saying that the problem didn't exist in my program, but rather with Library X, that I use in the construction of my application? Would anyone say that my program was secure and flawless, and that all security problems were really with the various libraries? I do not believe they would. I think it is more likely that the hole would be identified with my application, as well as any other application that referenced the same library.

This issue may show up in several Microsoft browser products because they link to this library in several products, but the user is interested in which products using this library are affected, and could care less which specific library it is in. Those developing with these libraries might care more about which specific function/method call in which library has a problem, but the average Joe User probably doesn't even know that a program may be statically or dynamically linked to dozens, or even hundreds, of libraries from a number of different sources. All they know, and care about, is that if they run "Application X", they could be at risk of a security problem, data corruption, blue screening their system, etc.

So, in conclusion, it may be technically more correct that this issue is in a specific Outlook Express library, it is Internet Explorer 7 that is using it, and therefore it is Internet Explorer 7 that has the defect.

Iketchum, I may disagree with you, but I appreciate the level of civility and politeness in your last post. It is most refreshing. I know I can get a bit rude and insulting at time, especially when provoked by certain other users of this forum. A polite discourse is a welcome change of pace around here.

#22 By 17996 (131.107.0.105) at 10/20/2006 1:25:15 PM
#21, where do you draw the line between "part of IE" and not?

mhtml is a pluggable protocol provided by an Outlook Express DLL*. IE DLLs provide such protocols as http, file, ftp, javascript, and res. The Help and Support Center provides "ms-help". HTML Help provides "ms-its". Microsoft Office provides "mso-offdap".

Parties outside of MS have provided their own pluggable protocols, for example EMule installs the "ed2k" protocol.

Surely, flaws in these non-IE and non-MS protocols are not automatically flaws in IE?

It's analagous to flaws in ActiveX controls. If the Flash or RealPlayer ActiveX controls contain flaws, which can be exploited by viewing a page in IE, that surely is not an IE flaw. Similarly, a flaw in the Flash plugin for Firefox, or any other Firefox extension, is not a flaw in Firefox.

*This can be confirmed by going to HKEY_CLASSES_ROOT\Protocols\Handler\mhtml. You will see a CLSID value within that key. Then go to HKEY_CLASSES_ROOT\CLSID\{05300401-BCBC-11d0-85E3-00C04FD85AB4}\InprocServer32, and note that the default value points to inetcomm.dll. It's accurate to call inetcomm.dll part of OE, not IE, because:
1. IE7 does not ship with inetcomm.dll
2. IE security updates have never updated inetcomm.dll
3. OE security updates *have* updated inetcomm.dll
5. Microsoft has publicly stated it's part of OE

#23 By 37047 (216.191.227.68) at 10/20/2006 2:03:16 PM
I would say that the line is in who introduces the flaw, and how it is introduced. If I create a plug-in Active-X control for IE, and it causes a security hole, then it would be entirely my fault, and people would be justified in criticizing my control. However, if in creating my Active-X control, I link to a Windows DLL, and that causes a problem, then it is still my security problem, and blaming Microsoft, saying it is a Windows problem, not my applications problem, would not be well received at all. It would be my responsibility to fix the problem with my Active-X control, either by writing my own version fo the offending function, or using another third-party equivalent. But the security reports would list it as a problem with my control. They might also list the same problem with the Microsoft supplied DLL, but that would be a separate report.

Since this is caused by Microsoft linking this DLL with the new Internet Explorer, it is an IE problem. The fact that the DLL in question comes from another source only means that other applications might share this exploit. It is still the responsibility of Microsoft to correct this problem that exists inside Internet Explorer 7. If they link to it in IE, then it is part of IE, regardless of what project originated the DLL originally. Anything else is merely passing the buck. Many managers in many companies have done this, and continue to do this. Microsoft is no different in this regard. In order to fix this, they may have to include a fixed version of this DLL in a future IE security patch or service pack.

#24 By 21203 (208.252.96.220) at 10/20/2006 3:23:14 PM
#23 - "Since this is caused by Microsoft linking this DLL with the new Internet Explorer, it is an IE problem."

Faulty logic. You might as well say everything in Firefox is a Windows problem since it runs on Windows. IE is an application launchpad in this case, nothing more. There are oodles of applications that extend from the IE interface, and always have.

#25 By 17996 (131.107.0.105) at 10/20/2006 3:34:35 PM
#23 - IE is not "linking to" inetcomm.dll. It is loading inetcomm.dll because it is registered for the mhtml protocol as I described above.

It is exactly the same situation for mhtml as it is for ms-help, mso-offdap, ed2k, or any other non-IE protocol. It's not a bug in IE7 and there is no fix within IE7 that can prevent all third-party pluggable protocols from screwing up.

Write Comment
Return to News
  Displaying 1 through 25 of 327
Last | Next
  The time now is 5:56:40 AM ET.
Any comment problems? E-mail us
User name and password:

 

  *  
  *   *