264944 - (Zalewski) Bugs found with Zalewski's mangleme (Bugtraq: "browsers, a mini-farce")

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Tracking, defect)

Description

[Daniel Veditz [:dveditz]]

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]]

Attachment: input element crash

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: attack of the marquees

Comment 3

[Daniel Veditz [:dveditz]]

Attachment: col span demo (non-crashing)

Comment 4

[chris hofmann]

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]]

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]]

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

(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-4, no longer working on Mozilla)]

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-4, no longer working on Mozilla)]

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-4, no longer working on Mozilla)]

attachment 162509 [details] does not crash for me.

Comment 11

[Daniel Veditz [:dveditz]]

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]

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]]

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]

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

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

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

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

(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 [e-mail] [e-mail]]]

URL is a slightly modified version of the test program.

Comment 20

[Jo Hermans]

*** Bug 265091 has been marked as a duplicate of this bug. ***

Comment 21

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(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) (inactive)]

*** Bug 265115 has been marked as a duplicate of this bug. ***

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yeah, right, (1<<31 - 1). :-)

Comment 24

[Brendan Eich [:brendan]]

> 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]

there is another crash (bug 265181) with bogus html when hitting reload on the code.

Comment 26

[Ryan Polk (Quark)]

*** Bug 265247 has been marked as a duplicate of this bug. ***

Comment 27

[Bill Mason]

*** Bug 265294 has been marked as a duplicate of this bug. ***

Comment 28

[Jacek Piskozub]

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]

*** Bug 265519 has been marked as a duplicate of this bug. ***

Comment 30

[Keith Gable]

*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]

Attachment: crasher not viewing as a file:///

crasher, but not viewing as file:///. Might work off of bugzilla.

Comment 32

[Daniel Veditz [:dveditz]]

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]

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]

(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]

..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 [e-mail] [e-mail]]]

(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 (they/them - no direct email)]

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]

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]

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 (they/them - no direct email)]

(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]

Another, similar fuzz testing tool: http://toadstool.se/software/iexploder/.

Comment 42

[Ben Fowler]

(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]

I filed bug 316894 to track bugs found by IExploder.

Comment 44

[Jesse Ruderman]

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 C]

Shouldn't this bug be moved to a Core component?

Comment 46

[Woody]

Works fine

Comment 48

[BMO Automation]

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.