Categorized | Security

IE 0-Day Shows Microsoft Developer Error

After blogging about the new unpatched vulnerability in Internet Explorer I became curious about something: Why wasn’t mscorie.dll linked with the /DYNAMICBASE option? This option enables ASLR (Address Space Layout Randomization), the absence of which is the door through which the exploit walks into remote code execution land.

mscorie.dll.pngmscorie.dll is identified as the “Microsoft .NET IE MIME Filter.” In a knowledge base article which describes the interactions between IE and .NET, its function is described:

The .NET Framework includes two components that handle the .NET Framework components in Internet Explorer. The first component, Mscorie.dll, contains a Multipurpose Internet Mail Extensions (MIME) Type Filter. This filter hooks into Internet Explorer and monitors all incoming data streams with the MIME type application/octet-stream. A primary role of this startup shim is to examine the incoming stream to see whether or not the stream is a managed code. If the filter determines that the incoming data is not a managed code, the filter allows Internet Explorer to handle the data the way that it did formerly.

As a workaround, Microsoft recommended that users “rebase” all DLLs used by Internet Explorer using their EMET tool. This has the same effect on the DLL as if the developers had used /DYNAMICBASE at link-time. But if there is a good reason why they didn’t use it, there may be side-effects of the change which we should know about. If there is no reason why, why not?

I asked Microsoft about this and the response from Dave Forstrom, Director, Trustworthy Computing, was:

Microsoft’s analysis does not indicate any potential problems by rebasing mscorie.dll.

So why didn’t they do it to begin with? It turns out that /DYNAMICBASE is only recommended and not required by the Microsoft SDL (Security Development Lifecycle). That, in and of itself, is not a reason not to do it, but it’s a reason why it might pass inspection.

Still, statically-based DLLs are one of only a few ways to get around the combination of DEP+ASLR. I would expect Microsoft to start flushing out cases like these and rebasing the files where possible. If there’s no reason why you shouldn’t run EMET for this, then there’s no reason Microsoft shouldn’t have used /DYNAMICBASE.



– on Security Watch

Related Posts

Comments are closed.

Security Status

Beware Facebook "Timeline" scams http://t.co/W5EW0cVv
5 months ago
Nigerian government (unknowingly) hosts phishing website http://t.co/uQd42ENw
5 months ago
PCMag Awards McAfee All Access its Editors’ Choice: SANTA CLARA, Calif.--(BUSINESS WIRE)--McAfee today announced... http://t.co/FakV7Vd8
5 months ago
RT @mikko: I hadn't noticed Google Maps has added 3D models of buildings. Here's a (very accurate) view of F-Secure HQ in Helsinki http://t.co/IKfAZlak
5 months ago
North Koreans aren't known for their online presence. But others may be lured into clicking Kim Jong-Il 'videos' too http://t.co/yQOon6YT
5 months ago
How to Protect Your Professional Reputation on Facebook Timeline http://t.co/I4bcR2VN
5 months ago
This is pretty impressive from @Softpedia: Facebook scans 2 trillion link clicks and blocks 220 million posts each day http://t.co/vKsn9gNl
5 months ago
Need for integrated approach to security in industrial control systems - http://t.co/tPBCNOow with @PikeResearch
5 months ago
Some free-based music we play at work http://t.co/xu5agZfc
5 months ago
Japan’s cyber defense weapon: a virus. It includes quotes by @Luis_Corrons via @InfosecurityMag
5 months ago