Microsoft Says Upgrade To IE8, Even Though It's Vulnerable

Barence writes "Microsoft has issued a statement urging people to upgrade their browser to IE8, after the zero-day exploit that was used to attack companies such as Google went public. According to Microsoft's security advisory: 'the vulnerability exists as an invalid pointer reference within Internet Explorer. It is possible under certain conditions for the invalid pointer to be accessed after an object is deleted. In a specially-crafted attack, in attempting to access a freed object, Internet Explorer can be caused to allow remote code execution.' But, although IE6 has been the source of the attacks until now, Microsoft's advisory admits that both IE7 and IE8 are vulnerable to the same flaw, even on Windows 7."

Comments

IE8 has the flaw but is immune...

[vistapwns]

Because DEP is enabled by default in IE8, unlike IE6 and IE7. The exploit can not work against IE8. Also, IE in modern versions of Windows is sandboxed, unlike Firefox. Sorry to rain on the parade...

Re:IE8 has the flaw but is immune...

[Ralish]

They are aiming for both backwards compatibility and security, but above all, they are aiming to put out a fix that isn't broke. I'm honestly not trying to be the Microsoft apologist here, but the complexity of putting out a patch for IE is a lot more complex than you might first think, even compared to other browsers. Here's why:

Using Firefox as an example, when Mozilla finds a security flaw in Firefox, they simply release a new point release of all supported versions of Firefox (currently 3.0 and 3.5) that contains the fix, as well as all previous fixes, and usually several other security/stability fixes bundled into that particular point release. So, this means a release across two product versions, which can be expanded to releasing on the architectures supported for those particular versions as well as supported platforms. The source code change probably isn't architecture or platform specific (wrong?) so can thus be inserted into the correct maintenance trees in the source repository and the binaries/sources made available.

Using Microsoft as an example, when Microsoft finds a security flaw in Internet Explorer, they need to patch every supported version of IE on every supported version of Windows down to specific IE patch level possibly also impacted by Windows patch level. For a security flaw like this that affects IE6 through IE8, that means patches for every version of Windows from 2000 to 7, for every architecture (x86, x86_64, ia64), for numerous patch levels. For example, in many versions of Windows two separate patch levels of IE might be simultaneously supported (e.g. IE6 SP1 on Windows 2000 and IE6 SP2(SP3?) on XP). Keep in mind that the binaries for the same exact patch level of IE on two different versions of Windows on the same architecture are highly unlikely to be the same (e.g. IE7 on XP will not be the same as IE7 on Vista, nor will the patch binaries be the same, and OS SP level may also make a difference). Versions of Internet Explorer on Windows CE/Mobile might also be impacted resulting in further patch complexity. Oh, and x64 versions of Windows (and ia64?) have both the 32-bit and 64-bit versions installed side-by-side, due to issues with plug-in compatibility (you can't load 32-bit code into a 64-bit application). So, you'll need to patch both versions on 64-bit platforms, and once again, the 32-bit binaries for 64-bit systems are unlikely to be identical to the 32-bit binaries for 32-bit systems. In summary, we are talking a huge number of binary patches that all need to be thoroughly tested, passed through regression suites, and so forth, because if even one of these patches breaks something, odds are, you'll have a lot of pissed off users.

That being said, this is largely Microsoft's fault. By integrating the browser so closely to the OS, they've managed to create this complexity. A clean(er) separation of web browser from OS internals would, while not making things simple, would surely reduce the current clusterfuck. Doing so would bring you much closer to the model that most (every?) other web browser uses, and should drastically reduce the amount of testing that would need to be done. For now, this isn't the case, and the present reality is that patching every version of IE since 2001 is a very messy business.

Re:Faulty Products. A comparison.

[plague3106]

Your memory fails you. Firestone said the problem was that their tire wasn't rated to the standards which were required for a particular Ford model. Ford installed them as OEM tires anyway. When it came out, Ford said Firestone made a faulty tire, but Firestone responded that the tire wasn't designed to be used in the environment created by Fords one SUV model.

As usual, another analogy on /. fails...