Crashing Browsers with HTML: Big Deal!

 
 
By Larry Seltzer  |  Posted 2003-05-22 Email Print this article Print
 
 
 
 
 
 
 

Many scary-sounding vulnerabilities just don't amount to a hill of beans in the real world.

Its not uncommon in the browser-vulnerabilities business to hear about an issue that crashes the browser. Most of the time you hear about Internet Explorer—justifiably so, since its the one nearly everyone uses. Other browsers have these same problems, too. You just dont hear about them for the same reason you dont hear about the things they do well: Nobody cares.

Obviously its not a good thing for the browser to crash, but its not that big a deal. As much as people are outraged when another one is discovered, none of these vulnerabilities ever become widespread. They dont spread themselves, and any Web page that implemented them would be offline before too long.

The latest one to get attention is an embarrassing one for Microsoft. All you need in the Web page is <input type>; legal HTML would have a word after type, and it appears IE just assumes there is one. When the parser fails to find one, a null pointer is used to define the type. (See this detailed explanation on the BugTraq mailing list if youre really interested in how the bug works.)

So you load a page with this bum tag in it, and Internet Explorer magically disappears. Should you fear this? How would it happen to you? Anyone who put this combination in a legitimate Web page would quickly discover his or her error. An illegitimate page wouldnt get visited all that often. I also tried putting it into an HTML e-mail, and somehow the type clause got stripped out by the sending client (Outlook 2002). <input> alone doesnt cause the crash.

IE is not alone in these problems. This line will start opening endess windows on any version of Mozilla or IE:
    <script> for(;;){window.open();} </script>
Its pretty ugly, and you end up having to terminate the browser process with extreme prejudice. This is a very old problem, and Im not sure why it hasnt been fixed; but then again, Im not sure how it could be fixed either.

This innocuous-looking code crashes all but the most recent versions of Netscape 4.x:
    <table><tr><td style="padding: 5">
      <blockquote>some text</blockquote>
      <table><tr><td>some text</td></tr></table>
    </td></tr></table>

Why do some of these bugs live on? Like all software developers, browser writers have to set priorities in the bugs they will fix, and these bugs are comparatively minor in terms of the security problem they present.

Of course, absent a "real" security problem, like a buffer overflow, there are other browser-based problems that can matter, such as spoof pages that try to steal your eBay password. But these are not software flaws, and its hard to imagine a technological solution to them.

So not every bug in an Internet-facing application is a security bug, and not every potential security bug is going to be worth worrying about. From the attackers point of view, some of this stuff just isnt worth exploiting. Some of these bugs may eventually go away as virtual environments like Java and .Net become more practical for end-user applications and we can throw CPU power at the problem more freely. But in the meantime, dont get too worked up over every bug that comes along.

Security Supersite Editor Larry Seltzer has worked in and written about the computer industry since 1983.
 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel