Over the past few years, Microsoft’s Internet Explorer has had a series of security vulnerabilities that made users susceptible to, at worst, remote code executions, which could allows malicious programs to run on the user’s computer without user intervention.
A buffer overflow is one of the ways to allow remote code executions to occur. In a nutshell, a buffer overflow occurs when program allocates some space in memory to store data, but the amount of data received is larger than the allocated memory, causing an “overflow” of data onto other parts of the memory, which may end up being a portion that the operating system has marked for executable data.
When programs are properly written, buffer overflows shouldn’t happen. The program should be validating the incoming data and only accept enough data that it won’t cause a buffer overflow. However, it’s easy to overlook security issues when the objective is to write a piece of software that runs and does its job.
Internet Explorer has has its share of buffer overflow problems. It is a large piece of software that has been developed over a long period of time, small security problems are likely to exist all over the browser.
One way to eliminate a buffer overflow type error is to use a platform that doesn’t allow buffer overflows to occur. Microsoft’s .NET Framework Common Language Runtime (CLR) is one such platform. Like Java which uses bytecode and a Java Virtual Machine to execute programs, the CLR runs as a virtual machine, which runs applications written and compiled for the .NET platform. The virtual machine performs checks on data that is being processed, and if it finds a problem, an exception will be thrown which in turn must be dealt with in some way.
Microsoft may want to consider start rewriting Internet Explorer with .NET. Running the browser on a virtual machine itself may already take a lot of the security risks that arise from exploits that use buffer overflows. There are of course other security issues that Internet Explorer have due to the features it support, such as ActiveX controls which can execute code directly on the user’s computer.
It may be interesting to note writing services in Windows with .NET and running it on the CLR was one of the original plans for Windows Vista, but eventually that was tossed out as it approached release.
Rewriting Internet Explorer may be a radical step to take, but considering that it is the browser with the top market share means that it should be taking the security of its software seriously. Writing Internet Explorer for the .NET Framework may be one way that Microsoft can be a responsible citizen and provide a product that is a little bit safer than it is today.