Microsoft warned today that hackers have published instructions for attacking a previously unknown security hole in all versions of Windows that could be exploited to siphon user data or trick users into installing malicious code.
Redmond published an advisory about a vulnerability in the way Windows handles MHTML code that could let attackers run Javascript code if the user is browsing a malicious site using Internet Explorer. As Wolfgang Kandek, chief technology officer at Qualys notes, that means that IE is the only known exploit vehicle for this flaw, and that other browsers such as Firefox and Chrome are not affected in their default configuration because they don’t support MHTML without the installation of specific add-ons.
Microsoft said it may issue a patch to fix the flaw, but that in the meantime IE users who are concerned about this threat can use a supplied “FixIt” tool to help shore up the way Windows handles MHTML documents. The enable that fix, visit this link and click the FixIt icon.
Related posts:
- Exploit Published for New Internet Explorer Flaw
- Microsoft Warns of Uptick in Attacks on Unpatched Windows Flaw
- Exploit in the Wild for New Internet Explorer Flaw
- Patch for Critical Windows Flaw Available
- Unpatched Windows XP Flaw Being Exploited
Tags: 0day, ie, internet explorer, microsoft, Qualys, Wolfgang Kandek
9(unknown*no*no*0)&guid=ON){kind=small}
Hidden due to low comment rating. Click here to see.
Timely post. I just finished installing Chrome Portable and LastPass onto a Flash Drive for a more secure “mobile browsing solution”. Have stopped using IE on Desktop except to check how websites look in it as many will look fine in Firefox and Chrome then have errors in IE.
Hidden due to low comment rating. Click here to see.
Sure would be great if all my clients gave up on IE; as then I could stop running the minefields for them. I’ll just keep stepping on them, to see what problems they will inevitably run into.
How long before we start seeing malicious fake “Fix It” pages? Or have I just missed them?
“that means that IE is the only known exploit vehicle for this flaw, and that other browsers such as Firefox and Chrome are not affected”
I’m shocked. Really.
The Opera web browser is reported to provide native MHTML support:
“Microsoft warns of new Windows zero-day bug
http://news.idg.no/cw/art.cfm?id=11DD262C-1A64-67EA-E4C8B9EBB3FB33A1
Will this published exploit work with Opera? Or is it specific to Internet Explorer?
Excellent post RHM!
Wow I did not know that Opera was also a risk! I am reading this right now with Opera! What do I do?
is this fix-it tool something an individual home user should use? it sounds like it’s for the corporate IT person.
I ran it. I’m not taking any chances. I won’t click through warnings. The tool seemed to install smoothly on Vista x64. If it reacts in a way you don’t like or expect, you can always click “Un Fix-it”.
thanks.
Hidden due to low comment rating. Click here to see.
I love Microsoft Windows, these exploits are like being enrolled in the jello of the month club, the gift just keeps on giving all year long.
Nothing to get too excited about here. It’s an information disclosure issue, not a remote code execution one.
More info here:
http://www.pcworld.com/businesscenter/article/218135/windows_vulnerable_to_zeroday_xss_attacks.html
brian: i don’t suppose you can get ms to change their site to link to https: for the fixit?
Not sure what encrypting the connection is going to add. The FixIt’s are Windows Installer files (ex. MicrosoftFixit50602.msi) that reside on download.microsoft.com. As long as you download them only from Microsoft you’ll be fine. If you wish to verify them further, check their digital signatures either by clicking “Publisher: Microsoft Corporation” if using the “Run” option or if using the “Save” option (Download the file to a directly on your system) right click the file, click properties and click Digital Signatures.
Oops, that should be “Download the file to a directory on your system”.
The trick is “ensuring that you only download them from microsoft.com”.
If you walk into a coffee shop and use WiFi, then it might be the case that someone has replaced the WiFi access point with one where they run DNS so that your lookup for microsoft.com/ns1.msft.net/download.microsoft.com goes to someone else.
(Note that the actual weak trust chain is considerably worse here, since first we’re reading krebsonsecurity via http, then we’re linked to a blog site [technet], then we’re linked to download.microsoft.com. Any of these pages could be replaced and send you somewhere else.)
While you might be smart enough to know that a fixit is an MSI, and that they should have a digital signature from Microsoft, do you believe that everyone else knows this?
As with ATMs, it’s easier to trick the user before the user gets to the goal. (Consider the latest article where the skimmer is deployed at the door instead of at the ATM.)
The same problem applies with looking up bank phone numbers — using http: on a bank you trust to look up phone numbers for the bank is *NOT* secure, sure you don’t care about privacy, but without the certificate you can’t be sure that no one has tampered with your connection and replaced the data for the page(s) you’re retrieving.
We’re slowly getting to the point where people barely understand that there might be reasons to use https (thanks to the Tunisian government for forcing Facebook to add this, even Firesheep failed) beyond secrecy. But people still don’t understand that part of the value of https is authenticity.
https does the following:
1. it asserts that for limited time interval •t to •t1 (which must include •now) the server •s to which you are connecting was trusted by agent •a which was trusted by agent •ca (at at time •t2) to issue certificates.
2. it enables you to automatically verify that you still trust •ca, that •ca still trusts •a. Potentially •a can indicate that it still trusts •s.
3. it enables you to trust that the traffic being sent by •s was indeed sent by a server trusted to act as •s.
4. it happens to enable the traffic between •s and you to be sent encrypted so that only your useragent and servers trusted per §1 will be able to easily decipher the communication for the next 3 or so years.
Some things https does not do:
1. https does not guarantee that your encrypted conversation can never be decrypted by anyone else. It just ensures that it would be relatively hard to do so in reasonable time at this time.
2. https does not guarantee that the server •s that you’re speaking to hasn’t been misconfigured, vandalized, hijacked, or rooted.
3. https does not prevent malicious software running on your computer, nefarious addons in your browser, or hardware devices attached to your computer from seeing your encrypted conversations (this is the flipside of 2 and is roughly where ZEUS and friends fit into the picture).
Is the workaround reversal registry changes scope too broad – it removes *all* restricted protocols, not just the MHTML ones?
Is the cure worse than the disease?
@MrUnFixitMaybe – good catch. The security advisory (2501696) gives the registry settings that are applied by the Fixit and the Unfixit. Instead of using the UnFixit, you can manually remove only the MHTML keys that are added by the Fixit, but few people are going to do that. MS needs to correct the UnFixit.
Given the time taken for Redmond to construct and publish a Fixit that is most times over aggressive, they could hunker down and roll out a permanent fix.
“The enable that fix, visit…” doesn’t quite make sense.