|
|
|
|
| |
Credit:
The information has been provided by Michal Zalewski.
To keep updated with the tool visit the project's homepage at: http://lcamtuf.coredump.cx/
|
| |
The tool generates a basic set of badly mangled tags on request, with auto-refresh back to the script, so that you can point a browser to it once, and let it run until it crashes.
An improved version by ned resulted in the discovery of MSIE IFRAME overflow and the birth of Bofra worm.
Download Information:
The tool's source code can be found at:http://lcamtuf.coredump.cx/soft/mangleme.tgz
Usage:
Put it in your cgi-bin directory or any other Apache folder with ExecCGI option enabled, then visit the URL
http://<yourserver>/<cgidir>/mangleme.cgi.
When the browser crashes, error-log should be examined for the last matching entry generated by mangle.cgi; extract the hexadecimal value, then invoke remangle.cgi?hex_value from the browser again. If it crashes, you've reproduced the problem, and can save the remangle.cgi page using wget or such. Check gallery/ for some samples.
A "lite" live demo (one refresh) 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.
Methodology and targets:
Michal 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).
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.
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
This 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 > This issue has not been fully researched.
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.
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.
Vendor notification, exposure, etc:
Some vendors received a brief advance notice on some of the first issues discovered. It is not, at this time, possible 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.
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 Michal 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; It is not possible to 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.
|
|
|
|
|
|
|
