Date: Mon, 18 Oct 2004 16:18:53 +0200 (CEST)
From: Michal Zalewski <lcamtuf@...ttot.org>
To: bugtraq@...urityfocus.com, full-disclosure@...sys.com,
	vulnwatch@...nwatch.org
Subject: 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:

    http://lcamtuf.coredump.cx/soft/mangleme.tgz

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

    http://lcamtuf.coredump.cx/mangleme/mangle.cgi

  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):

  http://lcamtuf.coredump.cx/mangleme/gallery/

  * 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
    compile.

  * mozilla_die2.html

    Bogus pointer access triggered by a unusual combination of visual
    elements.

  * 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 ;)

Thanks,
-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2004-10-18 12:35 --

   http://lcamtuf.coredump.cx/photo/current/

Powered by blists - more mailing lists