Is there a new remote data execution exploit for IE7?

All that anyone knows for certain as of today is that there are some browsers that appear to be the victim of new attacks using a very old profile: embedded binary code for graphic objects appearing in IE7 Web pages.

In a security advisory issued yesterday, Microsoft acknowledged that its security team is investigating reports of a new data execution prevention exploit in Internet Explorer 7 that was not addressed during the previous Patch Tuesday cycle, though it stopped short of explicitly saying such an exploit actually exists.

The advisory says the company is aware of certain attacks, though the way it said so implied that Microsoft learned of these attacks through customers, not through research. Security firms that have contacted BetaNews thus far also appear to have been caught off-guard, saying only that their respective security products deliver full protection against the problem...whatever it is.

Once again, the best clue we have as to the nature of the problem lies in Microsoft's suggested workarounds for customers, which it says will protect them from experiencing the attacks' known symptoms. The number one measure it suggests customers should take is to set both Internet and Local Security zone settings (through the Security tab on the Internet Properties control panel) to High prior to running any page that uses an ActiveX control or Active Scripting.

This suggests that, at the very least, the profile of the attack is one of the oldest in the book -- in fact, it could essentially be an offshoot of the most prominent attacks that plagued the very first editions of Internet Explorer over a decade ago. Back then, IE enabled the use of (non-standard) HTML elements that triggered both the downloading and the embedding of ActiveX controls in Web pages. Essentially, browsers could acquire and run binary code directly from servers, and back before anyone thought twice about the security aspects of doing so, no user intervention was required whatsoever -- zero.

Today, the ActiveX mechanism still exists, though with substantially more safeguards to prevent that type of occurrence. And Microsoft has "deprecated" ActiveX as a way to get custom controls in pages, devising in its place a complex but very functional system based on parts of the .NET Framework, such as Silverlight, that do not require the online transfer of binary code and its subsequent execution.

It was a long-running patent infringement lawsuit with Eolas Technologies that forced Microsoft to disable the automatic triggering of ActiveX controls in Web pages. That inclusion of the trigger protection was actually bad for Eolas, which had an opportunity to benefit from the automatic triggering of executable code -- the concept that Eolas' patents protected. After the two firms settled in November 2007, Microsoft was allowed to remove the protection, in an IE7 update that was rolled out last April. Ironically, it could be the re-emergence of that code trigger that is leading to what Microsoft now perceives as evidence of a new ActiveX exploit.

But whose systems would be effected, after all this long time, and after ActiveX has become an historical remnant for many users? Many enterprises that use intranets as vehicles for deploying their in-house Web applications, which run through employees' browsers, continue to run on code created in the last decade -- code that includes ActiveX controls that IT departments don't know, or aren't skilled enough with Visual Studio to learn, how to replace.

A Secunia advisory updated this morning indicates that the exploit focuses on the browser's apparent inability to clean up memory after an embedded component -- if Microsoft's description is accurate, presumably an ActiveX control -- is bound to a page with multiple HTML elements that refer to it. For example, conceivably, a single component may be embedded once but replicated throughout the page; if those instances are all cleared, traces of the code may remain in memory.

That code may then presumably be executed without need for privilege, although Microsoft is saying that turning Data Execution Prevention on will disable this ability.