Web Browser Incompatibilities
Posted by Gunter Ollmann on August 10, 2008 at 6:52 PM EDT.
What a relief, Blackhat and DEFCON have drawn to a close, and I can finally escape Las Vegas. Six days straight in this Styrofoam-molded Disneyland for adults have left all the usual physical and mental scars. I feel like I should be wearing a “I survived Las Vegas” t-shirt – especially after fumbling around early this morning looking for anything with caffeine in it prior to getting on stage for my presentation.
Despite having the first early morning slot on a Sunday, I was pleasantly surprised to see so many people making it to the presentation – with the only noticeable absentees being the blokes I was out partying with the evening before (perhaps they decided to go to church instead? Hah).
The presentation itself went by without any problems and was well received, and there were a number of follow-up questions digging in to some of the finer points about the datasets and context.
Anyhow, following the talk I had a bit of a discussion about the merits of how corporates should be handling the threat of these mass defacements with drive-by download payloads – in the face of having to stick with old, outdated and insecure browser versions because of compatibility issues with legacy internal applications.
In a nutshell, if you read the whitepaper I helped produce on Web browser Insecurity – “Understanding the Web browser threat” – you’ll have seen that we found Firefox's updating mechanism to be the best of all the Web browsers, and that we believe that promptness in applying patches and updates is critical against today’s threats.
The problem though is that Microsoft Internet Explorer is pretty much ubiquitous as the Web browser of choice in the corporate world, and a high percentage of installations run out dated versions (e.g. IE 5 and IE 6). Most organizations will cite that the key reason for this is for compatibility for legacy and internally developed Web 1.x-2.x applications. And, depending upon how those critical business applications were originally created, there’s a high probability that updating the default IE 5 or 6 installation to the most secure IE 7 version will overwrite key ActiveX controls on the employees desktops and render those applications “broken”.
The Internet side of the threat to these organizations comes in to play because their employees now rely upon these very same insecure and outdated Internet Explorer technologies to surf outside of the intranet. Basically, the organization needs to make a risk evaluation of whether business continuity is more at risk of breaking the internal application (rather then fixing the application itself by removing that dated browser dependency) or from some Internet Web browser threat. If we were having this discussion a couple of years ago, then I think there may have been some kind of debate. Now, today, the risk of an internal compromise to business continuity by allowing employees to surf the Web with year-old Web browser technologies is fast approaching unity – i.e. you better have a good disaster recovery plan (if not, don’t worry, you’ll get a lot of practice refining it...).
OK, let’s pause for a second though. If you’re a corporate, and you can’t upgrade/update your Internet Explorer installation, why not run two different versions of Web browser on the same machine? Granted, you can’t install multiple versions of IE on the same host – but you can install any of the others (E.g. Firefox, Opera, Safari, etc.).
And that leads me to my recommendation really. If you rely upon an old version of Internet Explorer for business application compatibility, install a SECOND web browser for doing the "Internet stuff" (I’d recommend Firefox because of its security features and speed of auto-updating).
To get around some of the “employee compatibility” issues, how about having two icons on the desktop – one labeled “Work” (Internet Explorer) and the other “Internet” (Firefox) – so that users know which one to use (or not to use).
If you’re not already doing so, use a Web proxy service (I’d also advise you to make sure it includes URL filtering technology), and configure it to stop users from using the wrong Web browser accessing the Internet. I.e. use the Web proxy service to interrogate the USER-AGENT string of the request and, if it’s Internet Explorer, redirect them to an internal help page informing them that they’re using the wrong icon/browser.
Similarly, you can employ the same tactics for stopping them from using Firefox for internal “incompatible” applications.
Operating this way is no more difficult than educating your employees to use Word to open documents, and Excel to open spreadsheets.
Granted, there may be some internal issues/requirements for getting Firefox added to any standard or “gold” desktop builds, but you’ve got to be a little blinkered if you’re letting employees blindly surf the Internet with out of date Internet Explorer versions.
BTW – now don’t get me wrong, a current fully-patched version of Internet Explorer (i.e. version 7) is about as safe as any of the other popular Web browsers out there from a security feature perspective. But until you either fix all the incompatibility issues the latest IE version has with your internal applications, or you figure out how to run multiple versions of IE on the same desktop installation, you really should be looking at using an additional current generation Web browser technology for Internet surfing.
