An
article today on Zdnet News calls into question the security of the Firefox browser. In light of Firefox's many recent security-related patches, its developers and proponents are beginning to rethink the message that Firefox is more secure than Internet Explorer.
One of the IE advocates linked to an eWeek article called "
The Lame Blame of ActiveX". The author argues that 1) ActiveX security problems are just a small part of the overall IE security problems, and 2) Firefox is just as insecure since a user can run XPCOM (the Mozilla equivalent of COM/ActiveX) via a plugin.
I have to agree on both points. Firefox or Mozilla do not have any built-in security that prevent the user from accessing the operating system. It's just that no malicious coders have done it yet.
The more serious issue is that buffer overruns plague both IE and Firefox due to their C/C++ heritage. This allows virus writers to execute malicious code with elevated privileges on a user's system, possibly doing damage to a user's files or infecting their computer. Now while C++ has memory management that is available through its string, vector and auto_ptr classes, most programmers still don't use these features. I really don't know why this is, but I think it's generally because most developers code C++ like C. However, these features have been in the language since the 1996 Standard, so education is apparently not going to solve the problem.
So how do you eliminate these buffer overruns? Primarily it's an issue of automatic memory management. Both C# and Java offer this feature, and to me are the logical choices for building a new, improved browser.
There's a couple of major hurdles though. Although Java has made some real strides in speed over the last few years, I still don't think it could handle the performance requirements of rendering complex web pages efficiently. That leaves the open source community out of luck, since
there's no other free, efficient equivalent to the Java Virtual Machine. Microsoft has it much better since they are only interested in supporting Windows, and C# does just fine at that. However, you might notice they haven't rewritten
any of their major applications in C#. You can speculate at why, but I believe the primary reason is that
any C# code can be decompiled very easily. Yes, it's true that there are .NET obfuscators out there that could jumble their source code a lot, but it's a lot easier to figure out (and change) obfuscated C# than pure assembly language. The bottom line is that
Microsoft would have to change C# compiler to emit assembly code instead of CLR-compatible IL, but then they've lost their security advantages of running on the CLR. I don't believe we will ever see a major C# application shipped by Microsoft for these reasons -- their intellectual property would be at risk. (What does that say to the other companies that have embraced the .NET platform?)
So what's the solution?
What Microsoft should have done instead is add a C++-compatible layer on top of the Win32 API. In my view, this layer would translate between the C++ memory-managed types (like string, vector, auto_ptr and the like) and the Win32 C-compatible API (which works with pointers and low-level memory allocation). As with .NET, to qualify as "managed, safe code", a program would be required to use the managed API only. The Windows OS would automatically shut down any program that violated this contract and accessed the lower-level API.
What are the disadvantages to this approach? Yes, the managed API would be slower. So what? .NET is slower now for the same reason, and no one cares. Yes, you wouldn't be able to port your .NET Windows programs to Linux. Again, so what? No one does that beyond a few geeky folks.
Unfortunately, Microsoft will never do this. The .NET framework would have to be a complete disaster for them to rethink their current approach. We all know .NET isn't a disaster -- like Java, it's just not
very good. Bottom line: we will continue to live with buffer overruns and other constant security problems in both IE, Firefox and other browsers until someone decides that
a secure browser has to be built from the start, with a secure language & framework.
