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