Last Comment Bug 264944 - (Zalewski) Bugs found with Zalewski's mangleme (Bugtraq: "browsers, a mini-farce")
(Zalewski)
: Bugs found with Zalewski's mangleme (Bugtraq: "browsers, a mini-farce")
Status: RESOLVED INCOMPLETE
[sg:nse meta] Please file additional ...
: meta, sec-other
Product: Core Graveyard
Classification: Graveyard
Component: Tracking (show other bugs)
: Trunk
: All All
: -- critical with 26 votes (vote)
: ---
Assigned To: chris hofmann
: chris hofmann
:
Mentors:
: 265091 265115 265247 265294 265519 320928 (view as bug list)
Depends on: 264956 265027 265067 265068 265181 265404 265583 265585 265736 265846 265857 265867 265876 265892 265899 265902 265947 265973 265999 266015 266966 267669 268231 269095 269604 275912 287681 288931 291204 292279 299036 303433 303901 307259 317285 320459 323026 323385 323386 323389 325984 328946 338251
Blocks: fuzz
  Show dependency treegraph
 
Reported: 2004-10-18 13:22 PDT by Daniel Veditz [:dveditz]
Modified: 2016-07-15 12:13 PDT (History)
56 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
input element crash (25 bytes, text/html)
2004-10-18 13:23 PDT, Daniel Veditz [:dveditz]
no flags Details
attack of the marquees (361 bytes, text/html)
2004-10-18 13:23 PDT, Daniel Veditz [:dveditz]
no flags Details
col span demo (non-crashing) (58 bytes, text/html)
2004-10-18 13:24 PDT, Daniel Veditz [:dveditz]
no flags Details
crasher not viewing as a file:/// (62.88 KB, text/html)
2004-10-23 21:41 PDT, Keith Gable
no flags Details

Description Daniel Veditz [:dveditz] 2004-10-18 13:22:03 PDT
http://securityfocus.com/archive/1/378632/2004-10-15/2004-10-21/0

extract:

  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.

...

  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.
Comment 1 Daniel Veditz [:dveditz] 2004-10-18 13:23:10 PDT
Created attachment 162506 [details]
input element crash
Comment 2 Daniel Veditz [:dveditz] 2004-10-18 13:23:41 PDT
Created attachment 162508 [details]
attack of the marquees
Comment 3 Daniel Veditz [:dveditz] 2004-10-18 13:24:38 PDT
Created attachment 162509 [details]
col span demo (non-crashing)
Comment 4 chris hofmann 2004-10-18 13:28:19 PDT
has anyone gotten the page to render consistently in IE?

I've seen IE in SP2 show the fully rendered page once in about 10 attempts...
Mostly showing some mal formed html on the screen, and other times it makes it
to a black background -- and a status bar message "done, but with errors", and
only once did I see lyrics from Credence Clear Water Revival - Bad Moon on the
Rise...

Firefox first balked and showing the page because I didn't have latest java, but
when I updated I get part way though like with IE and then it seems to give up.
 I haven't seen any crashes...

chris h. 
Comment 5 Daniel Veditz [:dveditz] 2004-10-18 13:49:41 PDT
The input element crash (mozilla_die1.html) is a null de-reference in
nsCSSStyleSheet.cpp, line 3188 on the aviary branch:

      } else if (mContentTag == nsHTMLAtoms::input) {
        nsCOMPtr<nsIDOMHTMLInputElement> inputEl = do_QueryInterface(mContent);
        inputEl->GetChecked(&isChecked);
      }

The content tag is input, but inputEl comes back null and isn't checked. Right
above it is the same problem for an option element, but overall the file looks
like it handles pointer derefs safely. Was this section written by someone else?
Was there an assumption violated further up the call chain?
Comment 6 Daniel Veditz [:dveditz] 2004-10-18 13:58:13 PDT
The marquee one crashed on bad memory during a reflow, and I can't get the third
to crash on either a current trunk nightly or a firefox dev build.
Comment 7 Christian :Biesinger (don't email me, ping me on IRC) 2004-10-18 15:03:32 PDT
(In reply to comment #5)
> The input element crash (mozilla_die1.html) is a null de-reference in
> nsCSSStyleSheet.cpp, line 3188 on the aviary branch:

this was also reported in bug 264956
Comment 8 David Baron :dbaron: ⌚️UTC-10 (vacation, returning December 19) 2004-10-18 15:19:20 PDT
attachment 162506 [details] is causing an nsHTMLUnknownElement to be created whose tag is
nsHTMLAtoms::input.  That shouldn't be able to happen.
Comment 9 David Baron :dbaron: ⌚️UTC-10 (vacation, returning December 19) 2004-10-18 15:27:49 PDT
attachment 162508 [details] is crashing because we attempt to push a line during a
non-paginated reflow.  This happens because NS_MAXSIZE is, for some bizarre
reason, defined as 1<<30 instead of 1<<31, so we can get to be bigger than it.
Comment 10 David Baron :dbaron: ⌚️UTC-10 (vacation, returning December 19) 2004-10-18 15:30:13 PDT
attachment 162509 [details] does not crash for me.
Comment 11 Daniel Veditz [:dveditz] 2004-10-18 16:25:54 PDT
Comment on attachment 162509 [details]
col span demo (non-crashing)

This didn't crash for me either (see comment 6). Found it in the linked
gallery, but it wasn't mentioned in the Bugtraq announcement.
Comment 12 Parag Warudkar 2004-10-18 16:46:02 PDT
With FF PR 0.10, die_1 and die_2 crash. die_3 fails to load the applet. Talkback
reports were submitted for 1 and 2.
Comment 13 Daniel Veditz [:dveditz] 2004-10-18 17:07:14 PDT
We don't need any more talkback reports, thanks: we know where these problems are.

There *is* no applet in die3, these tests throw garbage at the client to see
what it does. The pages aren't expected to display anything useful, but the
client shouldn't die trying to deal with the errors.
Comment 14 Bernd 2004-10-18 22:42:57 PDT
I think I protected the third case in Nov 2002
http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLTableColElement.cpp#47
So it might be older netscape that is crashing on it and I fixed a couple of col
crash bugs over the last months (bug 239294, bug 240854, bug 230138)
Comment 15 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-10-19 05:53:37 PDT
Bleah. Dealing with integer overflow issues in reflow could be a really sticky
nasty mess.
Comment 16 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-10-19 06:06:36 PDT
> This happens because NS_MAXSIZE is, for some bizarre reason, defined as 1<<30
> instead of 1<<31

I suspect so that comparisons of the form "x < max" where max == NS_MAXSIZE succeed.
Comment 17 Bradley Chapman (not reading bugmail, still gone but not forever) 2004-10-19 06:17:58 PDT
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041018 Firefox/1.0

Instant death with attachment 162506 [details] and attachment 162508 [details]. Attachment 162509 [details]
causes a sharp spike in CPU activity, but no crash.
Comment 18 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-10-19 08:08:24 PDT
(In reply to comment #16)
> > This happens because NS_MAXSIZE is, for some bizarre reason, defined as 1<<30
> > instead of 1<<31
> 
> I suspect so that comparisons of the form "x < max" where max == NS_MAXSIZE
> succeed.

We could make NS_MAXSIZE be 2^31 - 1, which would mean all comparisons "x > max"
would always fail, but "x >= max" could still succeed.

Comment 19 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2004-10-19 08:42:42 PDT
URL is a slightly modified version of the test program.
Comment 20 Jo Hermans 2004-10-19 09:38:50 PDT
*** Bug 265091 has been marked as a duplicate of this bug. ***
Comment 21 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2004-10-19 11:20:36 PDT
(In reply to comment #19)
> URL is a slightly modified version of the test program.
http://ctho.ath.cx/tmp/tester2.php?seed=0
The window title of tester.php is the seed.  If you go to the tester2 url and
fill in the seed, it produces (nearly) identical HTML (the meta refresh is
different, and there's no page title).
Comment 22 Blake Kaplan (:mrbkap) (PTO until Jan. 2, 2017) 2004-10-19 14:45:26 PDT
*** Bug 265115 has been marked as a duplicate of this bug. ***
Comment 23 David Baron :dbaron: ⌚️UTC-10 (vacation, returning December 19) 2004-10-19 15:39:32 PDT
Yeah, right, (1<<31 - 1). :-)
Comment 24 Brendan Eich [:brendan] 2004-10-19 17:10:35 PDT
> Yeah, right, (1<<31 - 1). :-)

Which in C or a C-like language must be written ((1<<31) - 1), alas and of course.

/be
Comment 25 Bernd 2004-10-19 23:33:03 PDT
there is another crash (bug 265181) with bogus html when hitting reload on the code.
Comment 26 Ryan Polk (Quark) 2004-10-20 08:36:00 PDT
*** Bug 265247 has been marked as a duplicate of this bug. ***
Comment 27 Bill Mason 2004-10-20 13:11:42 PDT
*** Bug 265294 has been marked as a duplicate of this bug. ***
Comment 28 Jacek Piskozub 2004-10-21 05:15:01 PDT
There is no word >> Zalewski << neither in bug title nor in comments, hence the
dupes. So I add the word in both places.

(Yes, I've noticed the alias but that's not enough).

Comment 29 Jo Hermans 2004-10-21 15:35:11 PDT
*** Bug 265519 has been marked as a duplicate of this bug. ***
Comment 30 Keith Gable 2004-10-23 21:36:42 PDT
*very* strange. seed 0x638b2a6e crashes Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7.3) Gecko/20041021 Firefox/1.0, but if I use wget to download it,
the resulting HTML file does NOT crash it.

In more detail, http://localhost/mangleme/remangle.cgi?0x638b2a6e crashes me,
but wget'ing the same URL does not. I'll attach the file as wget outputted, and
maybe you can figure out wtf is up.
Comment 31 Keith Gable 2004-10-23 21:41:20 PDT
Created attachment 163186 [details]
crasher not viewing as a file:///

crasher, but not viewing as file:///. Might work off of bugzilla.
Comment 32 Daniel Veditz [:dveditz] 2004-10-24 01:00:35 PDT
From Michal Zalewski in Full-Disclosure/Bugtraq:

> For those interested in doing some of my homework, I've updated the tool,
> incorporating several minor changes to its semantics to make it somewhat
> more powerful: download http://lcamtuf.coredump.cx/soft/mangleme.tgz for
> version 1.2.
Comment 33 Peter Weilbacher 2004-10-24 05:24:46 PDT
Hmm, I used the last three days and now tested several thousand garbled pages.
Since the fix of bug 265404 the tool didn't find any new crashers. I guess
Michal has to come up with a new version. :-)

One strangeness I found, however, is that a few of the mangle.cgi pages seem to
manage to open the window of the JavaScript console. Not sure that this
is/should be allowed by a webpage. Whenever it happened I went back through the
last few realizations with remangle.cgi but could never reproduce it. The last
time it happened I was running
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a5) Gecko/20041024
with a fresh profile/default settings and no extensions.
Comment 34 Pavel Penaz 2004-10-24 07:28:14 PDT
(In reply to comment #33)
> One strangeness I found, however, is that a few of the mangle.cgi pages seem to
> manage to open the window of the JavaScript console. Not sure that this
> is/should be allowed by a webpage.

This is bug https://bugzilla.mozilla.org/show_bug.cgi?id=243170. Happens to me
every few seconds when running mangle.cgi script.
Comment 35 Keith Gable 2004-10-24 11:24:43 PDT
..hope I did this right..

if not, please tell me how I'm supposed to link external bugs. ^_^

(bug 265876 per the status whiteboard)
Comment 36 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2004-10-24 12:02:45 PDT
(In reply to comment #32)
> From Michal Zalewski in Full-Disclosure/Bugtraq:
> 
> > For those interested in doing some of my homework, I've updated the tool,
> > incorporating several minor changes to its semantics to make it somewhat
> > more powerful: download http://lcamtuf.coredump.cx/soft/mangleme.tgz for
> > version 1.2.

I updated my tester to use version 1.2 (see comment #21).
Comment 37 Robert Strong [:rstrong] (use needinfo to contact me) 2004-10-25 14:45:10 PDT
bug 265867 bug 265899 bug 265902 bug 265973 bug 265986 and bug 265999 which this
bug has been marked as depends on were all found using a similar technique.
Instead of using malformed html I used random but well-formed html with unusual
style attribute values (e.g. mainly large positive and negative values for
margin and padding along with float left or right would cause a crash). The
resulting testcases were all very small to start out with, easily reduced in
size (e.g. usually less than 1 KB), and all reproducible with Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041025.
Comment 38 Ben Fowler 2004-11-17 10:13:33 PST
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041107
Firefox/0.9.1+

I clicked on attachment id=162508 from comment 2, and this Fox, now 10 days
old went into some kind of infinite loop or hang; I broke into it with bt,
and found a stack trace 479 frames deep, with this repeating sequence:

#26 0x00f3dc84 in nsFrame::RefreshSizeCache(nsBoxLayoutState&) ()
#27 0x00f3dee0 in nsFrame::GetPrefSize(nsBoxLayoutState&, nsSize&) ()
#28 0x00ff4d50 in nsScrollBoxFrame::GetPrefSize(nsBoxLayoutState&, nsSize&) ()
#29 0x00f424c0 in nsHTMLScrollFrame::GetPrefSize(nsBoxLayoutState&, nsSize&) ()
#30 0x00ff96d4 in nsBoxFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&,
nsHTMLReflowState const&, unsigned&) ()
#31 0x00f42814 in nsHTMLScrollFrame::Reflow(nsPresContext*,
nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&) ()
#32 0x00f2e6f4 in nsBlockReflowContext::ReflowBlock(nsRect const&, int,
nsCollapsingMargin&, int, nsMargin&, nsHTMLReflowState&, unsigned&) ()
#33 0x00f289f4 in nsBlockFrame::ReflowBlockFrame(nsBlockReflowState&,
nsLineList_iterator, int*) ()
#34 0x00f27798 in nsBlockFrame::ReflowLine(nsBlockReflowState&,
nsLineList_iterator, int*, int) ()
#35 0x00f2709c in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) ()
#36 0x00f25950 in nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&,
nsHTMLReflowState const&, unsigned&) ()
#37 0x00f2e6f4 in nsBlockReflowContext::ReflowBlock(nsRect const&, int,
nsCollapsingMargin&, int, nsMargin&, nsHTMLReflowState&, unsigned&) ()
#38 0x00f289f4 in nsBlockFrame::ReflowBlockFrame(nsBlockReflowState&,
nsLineList_iterator, int*) ()
#39 0x00f27798 in nsBlockFrame::ReflowLine(nsBlockReflowState&,
nsLineList_iterator, int*, int) ()
#40 0x00f2709c in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) ()
#41 0x00f25950 in nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&,
nsHTMLReflowState const&, unsigned&) ()
#42 0x00f3e8d4 in nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*,
nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&, int, int, int, int,
int) ()
#43 0x00f3dc84 in nsFrame::RefreshSizeCache(nsBoxLayoutState&) ()
#44 0x00f3dee0 in nsFrame::GetPrefSize(nsBoxLayoutState&, nsSize&) ()
#45 0x00ffe5c8 in nsSprocketLayout::GetPrefSize(nsIFrame*, nsBoxLayoutState&,
nsSize&) ()
#46 0x00ff9a68 in nsBoxFrame::GetPrefSize(nsBoxLayoutState&, nsSize&) ()
#47 0x00ff96d4 in nsBoxFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&,
nsHTMLReflowState const&, unsigned&) ()
#48 0x00f58e60 in nsLineLayout::ReflowFrame(nsIFrame*, unsigned&,
nsHTMLReflowMetrics*, int&) ()
#49 0x00f293f4 in nsBlockFrame::ReflowInlineFrame(nsBlockReflowState&,
nsLineLayout&, nsLineList_iterator, nsIFrame*, unsigned char*) ()
#50 0x00f29168 in nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState&,
nsLineLayout&, nsLineList_iterator, int*, unsigned char*, int, int) ()
#51 0x00f28f24 in nsBlockFrame::ReflowInlineFrames(nsBlockReflowState&,
nsLineList_iterator, int*, int, int) ()
#52 0x00f27b10 in nsBlockFrame::ReflowLine(nsBlockReflowState&,
nsLineList_iterator, int*, int) ()
#53 0x00f2709c in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) ()
#54 0x00f25950 in nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&,
nsHTMLReflowState const&, unsigned&) ()
#55 0x00f3e8d4 in nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*,
nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&, int, int, int, int,
int) ()

Is anyone working on this? If so which bug number 
Comment 33 implies a fix
  
Comment 39 Ben Fowler 2004-12-01 00:57:26 PST
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041201
Firefox/1.0+

Further to my comment 38, the testcase 'attack of the marquees' no longer
crashes and quite possibly renders correctly.
Comment 40 Robert Strong [:rstrong] (use needinfo to contact me) 2004-12-01 03:08:43 PST
(In reply to comment #39)

> Further to my comment 38, the testcase 'attack of the marquees' no longer
> crashes and quite possibly renders correctly.
That was fixed with bug 265027 which this bug depends on.
Comment 41 Jesse Ruderman 2005-09-09 00:24:38 PDT
Another, similar fuzz testing tool: http://toadstool.se/software/iexploder/.
Comment 42 Ben Fowler 2005-09-09 03:10:55 PDT
(In reply to comment #41)
> Another, similar fuzz testing tool: http://toadstool.se/software/iexploder/.

See 
Bug 265375 "crash (double caption?) [@ nsCSSFrameConstructor::GetFrameFor]"
Bug 286877 "Browser freezind when/during test"
Bug 265376 "Crash when handling malformed HTML code 
    [@ nsGenericHTMLElement::GetOffsetWidth]"
Bug 265371 "Crash when ISINDEX is used with position: fixed 
    [@ nsBlockBandData::Init]
Bug 265721 "-moz-key-equivalent related Crash [@ nsRuleNode::WalkRuleTree?]"
Bug 124901 "Webclient won't load SSL pages with questionable certificates"
Bug 146468 "Gigantic form with many inputs eats up all memory"
Comment 43 Jesse Ruderman 2005-11-17 14:23:01 PST
I filed bug 316894 to track bugs found by IExploder.
Comment 44 Jesse Ruderman 2006-01-14 00:05:59 PST
Some pages generated by remangle.cgi cause Firefox to guess that the charset is  UTF-16.  This usually ends up looking like blocks of random Chinese characters (even in "view source") and doesn't do a good job of testing Firefox's HTML parser.  I worked around this by making this change to my copy:

-  printf("Content-Type: text/html\n\n<HTML>\n");
+  printf("Content-Type: text/html;charset=utf-8\n\n<HTML>\n");
Comment 45 Daniel Cater 2006-04-04 08:08:46 PDT
Shouldn't this bug be moved to a Core component?
Comment 46 Woody 2008-06-22 04:18:02 PDT
Works fine
Comment 47 Bob Clary [:bc:] 2009-05-20 17:14:50 PDT
*** Bug 320928 has been marked as a duplicate of this bug. ***
Comment 48 BMO Automation 2016-07-01 13:04:04 PDT
Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE.
If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work
being tracked. The Core: Tracking component will no longer be used.

Note You need to log in before you can comment on or make changes to this bug.