eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
One of the famous arguments for open-source software, made in “The Cathedral and the Bazaar” by Eric S. Raymond, is, “Given enough eyeballs, all bugs are shallow.”
The point is that open-source projects will have more people working on them and looking at the code, and therefore the chances that bugs will be recognized are greater. In the traditional centralized software company, where access to source code is restricted, great deliberate effort must be put into bug fixing, thus putting open source at an inherent advantage.
This world view is a truism to some people, conjecture to others. Id say its almost unprovable. But every now and then some evidence comes along that makes you wonder whether anyone was looking at the code in a supposedly well-scrutinized program.
The latest one is mangleme by Michal Zalewski. Its a brilliant, simple tool that does nothing but generate malformed HTML tags at pseudo-random. By running it as a CGI process and including a META REFRESH tag, you can have a browser automatically receive random erroneous input until the browser dies.
Turns out most browsers die quickly. Counter-intuitively (for most of us), Internet Explorer handled the dirty input well. “All browsers but Microsoft Internet Explorer kept crashing on a regular basis due to NULL pointer references, memory corruption, buffer overflows, sometimes memory exhaustion; taking several minutes on average to encounter a tag they couldnt parse,” he said.
Zalewski goes on to speculate that Internet Explorer has been subjected to testing with a tool like this. Id make the same guess, but it is only a guess.
What excuse do the other browsers have? Zalewski lists, among those browsers that crash regularly, Mozilla, Netscape, Firefox, Opera, Lynx and Links. I only tested Firefox and Lynx. The former crashed; the latter locked up. Incidentally, the source for the “page” that locked up Lynx is a good example of the sort of dirty input this tool generates:
You can imagine how easy it is for a programmer to blow off edge cases that deal with input like this because, well, who would send something like this? Years ago that attitude might have gotten you paid and made the customer happy, but standards have changed. Programs have to be abuse-proof.
Next page: The security angle.
Page 2
The security angle? Apart from the obvious fact that the browsers can be DOSd with such a page, Zalewski speculates that some of the crashes will translate to exploitable overflows. This is possible, but not necessarily the case. Further research may show this, and the programmers who now go to fix the parsing bugs will need to keep their eyes out for overflows that may have been overlooked for the same reasons the crashes were overlooked.
And like I said at the top, the lack of hardening to bad input is disappointing with respect to the failed products, most of which are open source. The actual file and tag parsers have to be among the oldest parts of the programs, and yet it seems they didnt get quite as much attention as they should have. The lesson is that we shouldnt assume somethings debugged just because everyone in the whole world has access to the source code. And sometimes the fact that its some paid persons job to debug means a better job will be done.
Of course, it would be precipitous in the extreme to jump to the conclusion that this means Internet Explorer is more secure than those other browsers, and Zalewski specifically did not make this claim. But we all owe him thanks for a simple, innovative tool that will help to make all of our browsers better.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.coms Security Center at http://security.eweek.com for security news, views and analysis.
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page: 
More from Larry Seltzer