Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Web Browser)  >   Opera Vendors:   Opera Software
Opera HTML Parsing Errors Let Remote Users Deny Service
SecurityTracker Alert ID:  1011811
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Oct 20 2004
Impact:   Denial of service via network
Exploit Included:  Yes  

Description:   A vulnerability was reported in Opera in the parsing of HTML. A remote user can create HTML that, when loaded by the target user, will cause the target user's browser to crash.

Michal Zalewski reported that certain HTML tag sequences and formatting can cause denial of service conditions.

An excessive COL SPAN within a TBODY section will trigger a crash.

Some demonstration exploit examples are provided at:

Impact:   A remote user can cause a target user's browser to crash when loading HTML.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Exception handling error, Input validation error
Underlying OS:  Linux (Any), UNIX (macOS/OS X), Windows (Any)

Message History:   None.

 Source Message Contents

Subject:  [Full-Disclosure] Web browsers - a mini-farce

Good morning,

I wanted to file a vague report a couple of potentially exploitable
vulnerabilities and DoS conditions in popular browsers, announce a useful
web browser testing tool, and stir some controversy - all in one short
post. Let me know how I doing.

1) Background - the tool

  In my spare time, I put up a trivial program to generate tiny, razor-sharp
  shards of malformed HTML. The program uses a refresh tag to repeatedly
  feed new data to the client, so testing can be pretty much unattended,
  except for the moments the browser crashes or stalls.

  The tool generates only basic HTML - no stylesheets, no scripts, mostly
  no browser-specific features - and is, by all accounts, rather dumb.
  Should you want to use it rather than spending 5 minutes to develop
  your own, much better alternative, the source for the program is
  available at:

  A "lite" live demo (ohne refresh, and with more fascist limits) is also
  available here:

  The program functions as a CGI script, and is best installed on
  LAN or local box.

2) Methodology and targets

  I ran the program against recent versions of several popular browsers,
  that is Microsoft Internet Explorer, Mozilla / Netscape / Firefox,
  Opera, Lynx, Links (the last two are included primarily because they're
  often deployed in non-interactive mode to render plain text views of
  HTML e-mail messages).

3) Results summary

  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 couldn't parse.

4) Sample flaws

  A gallery of quick examples I examined to locate the offending tag
  (total time to find and extract them - circa 1 hour):

  * mozilla_die1.html

    Appears to be a memory corruption / overflow problem; TEXTAREA,
    INPUT, FRAMESET and IMG tags followed by NUL, then a number of
    extra characters, cause the browser to die while accessing
    NULL pointer, loop forever, or die while accessing invalid
    pointer. My guess would be that they calculate tag length using
    strlen-alike function, but then copy till separator or > - but
    this is just a guess.

    The behavior is tag and OS-specific, and is likely exploitable with
    some luck in those of the cases that do not lead to NULL ptr. I didn't
    investigate - Mozilla sources are 220 MB, mostly C++, takes forever to

  * mozilla_die2.html

    Bogus pointer access triggered by a unusual combination of visual

  * opera_die1.html

    Excessive COL SPAN in TBODY causes Opera to go down in flames,
    attempting to make a reference to uninitialized memory. Probably
    can be exploited in right conditions.

  * links_die1.html

    Table of an excessive size causes links to DoS the machine
    by consuming all memory until calloc fails, then write over what
    it managed to allocate.

  * lynx_die1.html

    Lynx loops forever trying to render broken HTML.

  Rest assured, this is merely a top of an iceberg; there are more
  crashes and other problems than one can asses and evaluate while
  retaining sanity.

5) Vendor notification, exposure, etc.

  I gave some vendors a brief advance notice on some of the first issues
  discovered. I cannot, at this time, provide a full list of individual
  flaws and their ultimate impact. The above set of examples is most
  certainly incomplete.

  Consider this post a notice of a problem, and an invitation to identify
  specific issues; it is by no means comprehensive or definite. Feel
  free to check browsers - Safari comes to mind.

6) Pointless rants

  It appears that the overall quality of code, and more importantly, the
  amount of QA, on various browsers touted as "secure", is not up to par
  with MSIE; the type of a test I performed requires no human interaction
  and involves nearly no effort. Only MSIE appears to be able to
  consistently handle [*] malformed input well, suggesting this is the
  only program that underwent rudimentary security QA testing with a
  similar fuzz utility.

  This is of course not to say MSIE is more secure; it does have a number
  of problems, mostly related to its security architecture and various
  features absent in other browsers. But the quality of core code appears
  to be far better than of its "secure" competitors.

  [*] Over the course of about 2 hours; I cannot rule out it would
  exhibit problems in a longer run.

On a side note: as one could expect, feeding an URL to the aforementioned
CGI script to most online HTML validators, converters, translators and
other tools of this nature results in various amusing if spectacular
problems and crashes.

Side note #2: if your computer finds a problem using this tool and you
sell the finding to iDefense... well, that's cheating ;)

------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * []
    Did you know that clones never use mirrors?
--------------------------- 2004-10-18 12:35 --

Full-Disclosure - We believe in it.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC