IE Security Update Impact to Security and Compatibility


We’ve heard some concerns about the potential impact of recent IE updates, and I want to give you background on these updates so you can understand the impact.

It is a top goal of ours to keep users safe and web pages working as the author intended. The great majority of users and developers should not be negatively impacted by recent IE security changes. However, there is potential for any code change to change how a web page works, which is why we are very careful about deciding what changes we release.

The two most recent IE security updates, MS05-038 and MS05-052, include defense-in-depth improvements that help prevent malicious web pages from loading and manipulating ActiveX controls that were not meant to run in IE. Prior to MS05-038 and MS05-052, IE included two main security checks around whether an ActiveX control can load and be manipulated by a web page:

  1. Only allow ActiveX controls to load if they are not in the registry-stored “killbit” list
  2. Only allow loaded ActiveX controls to be manipulated if they have implemented IObjectSafety and therefore “promised” they can be safely scripted

MS05-038 strengthens the first security check by using standard Windows COM mechanisms to help decide whether an ActiveX control is valid. MS05-052 further strengthens this security check by removing legacy code that could be used to get around MS05-038. Furthermore, MS05-052 completes the IObjectSafety check earlier in the ActiveX loading process so that an ActiveX control is not fully loaded until it “promises” it is safe for scripting. As a side note, these fixes are in line with the ActiveX Opt-in feature we’re shipping in IE7 to reduce IE’s attack surface.

While testing these security updates we ensured that the most popular ActiveX controls continued to work, including Macromedia Flash, Sun Java, Apple Quicktime, Real Player, Windows Media Player and Adobe Reader.

We do know of one compatibility problem, which prevents ActiveX controls from loading in IE. When a user has Vignette’s Business Integration Studio installed, this application modifies COM registry keys now used by IE security checks. Vignette is aware of this problem and already has a solution available through their support web page. If you do not have Vignette’s application installed and you still find that no ActiveX controls are loaded in IE, you can work around the problem by resetting the COM registry keys back to their original values as outlined in KB Article 896688. Otherwise, everything should work as expected.

 – Marc

Comments (23)

  1. Anonymous says:

    When can we expect another IE beta? All these changes are well and good, but it would be better to have a large community testing on a daily basis these changes, vs just the devs poking around.

    >It is a top goal of ours to keep web pages working as the author intended.

    Why don’t you just make them work as the W3C intended them? Authors intentionaly code web pages wrong because IE displays them wrong. Just make them work the right way, and the authors will fix their code.

    This is probably part of a scheme to purposely have authors code incorrectly so that when they are rendered in IE it’s fine, but when they’re rendered in a standards compliant browser (like Firefox) it displays not as the author intended it. Then people blame it on Firefox (not IE, where the blame really lays) and then they come running back to IE. It’s a conspiracy I tell you.

  2. Anonymous says:

    IE7 Beta 1 was made "available to MSDN subscribers and a pretty small set of pre-enrolled beta test participants" according to http://blogs.msdn.com/ie/archive/2005/07.aspx

    Furthermore, it states that they plan to "release Beta 2 much more broadly"

    Based on Microsoft’s history, they often release software in a smaller circle to sort out obvious problems prior to providing the software to the public.

    According to "Paul Thurrott’s SuperSite for Windows" (http://www.winsupersite.com/) IE7 Beta 2 will be released on December 7 and he often hits the mark … check out his website.

  3. Anonymous says:

    I frequent Paul Thurott’s site. My point is, Microsoft should release more frequent betas. Mozilla releases new testing builds for it’s products roughly once an hour. And all of their storage and bandwidth is donated from mostly colleges. I’m sure with all of Microsoft’s money and connections, they can swing a new testing build at least once every couple of weeks.

  4. Anonymous says:

    This sounds an awful like my notes on IObjectSafety:

    http://www.securityfocus.com/archive/1/391803

    It would have been nice to have gotten some feedbaack from MS when I originally reported this to them 6 months ago, rather than just ignoring my email to them.

  5. Anonymous says:

    Shane, you say MS "ignored" your mail. Your post over at Security Focus indicates that there was a vendor response. Which was it?

    The approach described above isn’t the one you suggested.

  6. Anonymous says:

    Will:

    The ‘Vendor’ response was basically, ‘it is by design that any activeX object can be started – we deny there is any flaw’. So they didn’t necessarily ignore the email, but they ignored/denied the problem.

    Now, From MS:

    "strengthens the first security check by using standard Windows COM mechanisms to help decide whether an ActiveX control is valid" – what are these extra checks exactly?

    "In IE7, we made sure that the only ActiveX controls available to IE were the ones intended for use on the internet. … While only some ActiveX controls were intended for use inside IE by web sites, many of them identify themselves as available for use inside IE. We decided that allowing ActiveX controls to run in IE should be the exception, not the rule. IE7 will block all ActiveX controls from running in the browser except for controls that were explicitly intended for the browser. That list is under the user’s control."

    "ActiveX Opt-in: To reduce the attack surface and give users more control over the security of their PC, most ActiveX controls (even those already installed on the machine) will be disabled by default for users browsing the Internet. Users will have the option to enable controls as needed using the same Information Bar they have used to install new controls since Windows XP SP2"

    From my post:

    "IE should show all components marked as safe in the manage add ons screen ("safe" objects on a system, effectively are IE add-ons, I believe the user should be made aware of them). This screen should have the ability to remove the ‘safe’ keys, and set kill bits for components that automatically re-add the keys or you don’t want to be prompted about.

    This can all be done via the ‘information bar’ with no annoying prompts to the user. There would effectively be no perceivable difference to the end

    user other than a safer browsing experience."

    I also went on about the problems of IObjectSafety and object instantiation – which they mention with "IObjectSafety check earlier in the ActiveX loading process so that an ActiveX control is not fully loaded until it “promises” it is safe for scripting." but don’t go into much detail about.

  7. Anonymous says:

    That is what I thought.

    Non-admin stops MS05-001 and similar even without the patch (same error on a page with exploit code is produced in an admin account with the patch as the non-admin account without the patch). I run as non-admin, but most people don’t run as non-admin, so this is really a step in the right direction.

  8. Anonymous says:

    We are an ISV that produces a popular ActiveX control called XStandard. IE 7 Beta 1 broke our software because it changed the way its ActiveX container handles drag & drop events. We had to release a special version of our software to address this change in IE’s behavior.

    We expect that Beta 2 will once again break our software because it will restrict our software from writing to any other folder other than "Temporary Internet Files". We fully understand why you are adding this particular feature and we will release another version of our software to adjust to this change (so long as we can create sub-folders in "Temporary Internet Files").

    We anticipate that you will probably put some restrictions on writing to the registry too. When our ActiveX control is downloaded in a CAB file by IE and registered, our control writes to the registry an association between CLSID and Content Type. We write to the following registry key:

    HKEY_CLASSES_ROOTCLSIDDatabaseContent Typeapplication/x-xstandardMIME

    So, can you please ensure that IE 7 still permits ActiveX controls to write to this registry key or please provide equivalent functionality?

    Also, we use this technique to mark our ActiveX as safe for scripting:

    ms-help://MS.MSDNQTR.2003FEB.1033/enu_kbvisualc/en-us/visualc/Q161873.htm

    Do we still need to implement IObjectSafety?

  9. Anonymous says:

    PatriotB and Redxii, you’re right that MS05-011 would not have occurred if ActiveX Opt-in was in place and blocked the HTML Help control from loading. Even if the HTML Help control did load in IE on Vista and the user is running as admin, Protected Mode would block the control from writing outside of the Internet cache.

    Shane, I’m sorry that you did not get more detailed feedback from Microsoft on your securityfocus post. IE7’s ActiveX Opt-in feature is very similar to what you describe above in that it does launch an Information Bar when an ActiveX control is not on the pre-approved list of ActiveX controls meant to run in IE and it also lists these Active controls in the Manage Add-ons dialog. I hope this addresses your concerns.

    Vlad, your current install format should continue to work in Protected Mode IE because during ActiveX registration via dllRegisterServer, an ActiveX control can write to the Content Typeapplication registry key. And yes, ActiveX controls that want to run inside the IE process and are safe for scripting by web pages should continue to implement IObjectSafety.

    -Marc [MSFT]

  10. Anonymous says:

    Marc, thank you for the response. We need clarification on two things:

    1. In IE 7, will ActiveX controls have the right to create sub-folders in "Temporary Internet Files"?

    2. For future releases, we will implement IObjectSafety. However, currently we implement this approach:

    ms-help://MS.MSDNQTR.2003FEB.1033/enu_kbvisualc/en-us/visualc/Q161873.htm

    Will security updates MS05-038 and MS05-052 affect operation of our software if it uses the technique above instead of IObjectSafety?

  11. Anonymous says:

    I’ve found what looks like a handle leak that occurs when 896688 patch is installed. Each time you reload a page IE creates new handles to the HKCUSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMap key. At first i thought it had something to do with an ActiveX control on the page, but then I tested it on a plain html file and got the same behaviour. It looks as if memory is leaking too, but it isn’t as noticable.

  12. Anonymous says:

    TomM: "I’ve found what looks like a handle leak that occurs when 896688 patch is installed. Each time you reload a page IE creates new handles to the HKCUSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMap key. At first i thought it had something to do with an ActiveX control on the page, but then I tested it on a plain html file and got the same behaviour. It looks as if memory is leaking too, but it isn’t as noticable."

    I don’t know if it’s to that exact key, but there are definitely new handles being made whenever I refresh this page. Refreshing "http://msdn.microsoft.com/vstudio/express/default.aspx" (the Microsoft Express Editions page) causes about a 41-handle gain (when the new page is fully up, minus those of the old page before hitting Refresh; some of the handles do "evaporate" away slowly, according to the Task Manager).

  13. Anonymous says:

    The original article said



    While testing these security updates we ensured that the most popular ActiveX controls continued to work, including Macromedia Flash, Sun Java, Apple Quicktime, Real Player, Windows Media Player and Adobe Reader.

    I would like to add that the Adobe SVG viewer does not work with this update. I suggest to add this control as well to the check list.

  14. Anonymous says:

    Sorry for posting in here, I am a newbie in here. I would like to ask about PNG bug. Link: http://castlecops.com/p656013-IE_PNG_Big_Bug.html

    One more question. Is it possible to add a feature to IE, that a user would be able to manage cookies (to delete only 1 cookie, to see the list of them) or edit passwords?

  15. PatriotB says:

    redxii — In this case (where the security vulnerability is in the ActiveX control itself), the vulnerability is still there and still represents a threat that needs to be fixed. So, I think you’ll still see these types of security bulletins.

    The key thing is that the impact rating will be much lower. So, instead of being Critical, it would be Low (for example)–because it wouldn’t be vulnerable by default and would take significant user interaction to enable it.

  16. Anonymous says:

    So basically with IE7 we will have default deny for ActiveX controls instead of default allow and killbits for controls that shouldn’t be used in IE? Just to clarify..

    For example, let’s take MS05-001 ( http://www.microsoft.com/technet/security/Bulletin/MS05-001.mspx ). Would that have occured if Opt-In were in place?

  17. Anonymous says:

    >While testing these security updates we ensured that the most popular ActiveX controls continued to work, including Macromedia Flash, Sun Java, Apple Quicktime, Real Player, Windows Media Player and Adobe Reader.

    Too kind! Any epitaph for small software vendors ?

  18. PatriotB says:

    Wait a second, is Vignette’s software deleting the class moniker from the registry altogether? What the heck would they do that for?! Sounds like they were just asking to be broken…

  19. Anonymous says:

    http://www.eeye.com/html/research/upcoming/index.html

    That page has vulnerabilties which just that one company "eeye" has found! And Microsoft has not yt fixed them. I wonder how many other bugs exist. Also, I have notice with just about all (havent checked every single one buy i havent found any counter examples) their security updates they thank third parties for finding the flaws. How is it third parties are able to find these flaws without access to source code?? Why isn’t microsoft internally finding any issues? They need to seriously sit down with all their code including ActiveX stuff and do a bounds/type check on every single variable derived from user input. Every time a piece of user input is utilized for something it should be checked for being within the range of expected values, length with bounds. This applies even for cases where the variable is created by parsing other input variables that may have been checked already.

  20. Anonymous says:

    Well the security update is so good, that I just got 2 cab files installed from a webpage. Thanks guys. Thanks a lot for nothing!