Internet Explorer Flaw, Transparency, and App Compat
“After IE Attacks, Microsoft Eyes Security Betas” is by Al Sacco at CSOOnline. He has a lot of good orientation and background. Then take a look at Mike Reavy’s “Third party solutions to the Internet Explorer CreateTextRange vulnerability.” Mike runs MSRC, and it’s a pleasant surprise to see him acknowledging customer fears with a post that ends:
Customers of course can weigh the risk of deploying a third party “patch” but it’s unclear what impact this will have on the system. Addressing the vulnerability, as well as working with partners to address attacks, are a few of the main things that we’re working on and we’ll keep you up to date as progress is made.
That was pleasant enough, but then later yesterday, Mike Nash, who runs the Security Technology Unit, chimed in with “An update on the IE ActiveX change.” That post contains this interesting tidbit:
So when we release the next cumulative IE security update, customers will only be able to interact with Microsoft ActiveX controls loaded in certain web pages after manually activating their user interfaces by clicking on it or using the TAB key and ENTER key.
So that’s very cool. Making ActiveX controls less dangerous is a fine thing. (I’m curious, though, what the user experience will be, and how easily people will be convinced to hit tab-enter?) I’m also really sort of confused by this decision:
Interactive controls are ActiveX controls that provide user interfaces. When a web page uses the APPLET, EMBED, or OBJECT elements to load an ActiveX control, the control’s user interface is blocked until the user activates it. If a page uses these elements to load multiple controls, each interactive control must be individually activated.
…
When a control is inactive, it does not respond to user input; however, it does perform operations that do not involve interaction. If, for example, you open a web page that uses Microsoft Windows Media Player to play a music file, the music plays after the page loads. You cannot interact with Windows Media Player until the control’s user interface is activated, as shown in the following figure.
From “Activating ActiveX Controls” on MSDN.
So, that’s sort of confusing to me. It sounds like ActiveX controls run, but to interact with them, you need to hit a special key first. App compat is broken, but the apps are allowed to run without controls? Why not delay the activation of the ActiveX until the user presses a key? Isn’t this a great opportunity because application compatability is breaking anyway to make a substantial change to the way ActiveX controls are activated that better protects customers?
(I wrote this two weeks ago, and forgot to hit “post.”)
The reason you may be confused about the ActiveX change is because it’s not actually a security fix. IE hotfixes are “cumulative”. That is to say that they maintain one codebase for each version/OS, and every update is tacked onto all updates prior to that point.
Because the April security patch entered development after the application of the February ActiveX update, it contained that update even though it wasn’t security-oriented.
The ActiveX update is Microsoft’s response to Eolas v. Microsoft, when it lost a patent lawsuit with the aforementioned plaintiff. The lawsuit covered, in a nutshell, the ability for web content to introduce plug-ins like ActiveX and allow the “instant interaction” with these plug-ins. Hence, Microsoft was forced to remove the ability for “instant interaction.”
To do so, it used this rather annoying fix. No security intent there, hence the confusion of one who is attempting to evaluate it from a security perspective.
So the trick is that to activate the control, you need to activate it first. That’s it, click the thing and it’ll work just like before…
Mario,
As I understand things, that’s not true. The code is activated when the page is loaded. The user-manipulable-controls are activated when you click it.
Which means that spyware installers with no UI work, and Seibel doesn’t.