IE security: naming and shaming (subtle or not)

Internet Explorer used to have plenty of security holes, but the last few versions have been pretty good in terms of security.
Written by Simon Bisson, Contributor and  Mary Branscombe, Contributor

Internet Explorer used to have plenty of security holes, but the last few versions have been pretty good in terms of security. No browser is completely secure, but Microsoft has actually been innovating in browser security for quite some time now; running IE in a low privilege protected mode (which isolates the browser and prevents reads and writes to the file system and the registry), scanning Web pages for malware and phishing attacks, checking whether you're downloading a known program or some new file that just happens to have the same name, using ASLR (Address Space Layout Randomization) so viruses can't just switch areas of memory with data in back to run as code…

Microsoft isn't shy about announcing its security improvements, but it tends to err on the side of politeness when partners aren't measuring up; look at how long it took to name Yahoo as the third party running up data usage on Windows Phone 7, or the way Microsoft would never name the device driver that caused 80% of crashes in Vista or the single IE plugin that is the number one cause of crashes in Windows. That's nice for the third-party developer that Microsoft is protecting; not so nice for the user who can't pressure that developer to fix their code (or just choose to uninstall it).

The Choose Add-ons dialog that pops up in IE9 soon after you install it is a welcome change; add-ons can slow down opening new tabs to the point that the whole browser feels slow and telling you that Skype adds 0.14 seconds and Java adds 0.13 seconds and the Microsoft 'search helper' adds 0.09 seconds means you actually know who to blame. (I'd like to see the same granularity in the interfaces that tell you about what ActiveX controls and ad tracking is blocked on the page instead of the current all or nothing options for turning them on and off - if I want Disqus comments but not Google Analytics on a page, I have to either go find all the Disqus options in tracking protection or turn on everything that's blocked on the current page.)

And I noticed another example in the IE blog today. There isn't a built-in tool for checking the security settings of add-ons for IE built in to IE 9 but there's a free tool that tells you whether add-ons you have loaded are running as low or medium integrity processes (low is the more secure option) and whether they use ASLR. It's called Process Explorer and you can run it directly from the Sysinternals site (go to http://live.sysinternals.com and click on http://live.sysinternals.com/procexp.exe); choose to Run the download rather than saving it and when it runs, right-click on the columns at the top and turn on the Integrity and ASLR entries. Then scroll down and take a look at the processes inside IEXPLORE.EXE.

On my system everything is using ASLR and I'm glad to see it. But the IE team has found an add-on that doesn't use ASLR and while it doesn't name it in the blog post, it's obvious from the accompanying image. Yes, we're looking at you, Google Update.

Is Microsoft being snide or subtle by using the image but not actually typing in the name? I'm not sure, but I'm glad to know about it - and the technique for finding out yourself is more useful than Microsoft just pointing the finger at Google about this incident. Now you can check other apps and plugins and hold the suppliers to account: complain, stop using the software or know that you're taking a calculated risk.

Not using ASLR for add-ons isn't the only way third-party developers don't do as much as they could to protect users. It took other browser vendors longer than I expected to adopt the low privilege mode in Windows; they may have looked at the low market share for Vista and decided the engineering effort wasn't worth it, but it's still disappointing to see Windows offer better security and have developers not take advantage of it as soon as possible. Similarly, it's hugely disappointing when installers, updaters and drivers aren't digitally signed for security; knowing where software really comes from is a big step forward for security and if your app isn't worth you spending $25 on a certificate, why should I trust any of your other coding practices?

Incidentally, I'm expecting plenty of comments telling me that IE does badly in terms of security; they'll be much more interesting if you can provide specifics and statistics rather than blanket declarations of opinion. Bonus points for comments that refer to recent versions of IE rather than ones that are ten years old (even if the UK government does still use IE 6) and that compare like with like.

Mary Branscombe

Editorial standards