Closed Bug 264944 (Zalewski) Opened 20 years ago Closed 8 years ago

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

Categories

(Core Graveyard :: Tracking, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: dveditz, Assigned: chofmann)

References

(Blocks 1 open bug)

Details

(Keywords: meta, sec-other, Whiteboard: [sg:nse meta] Please file additional crashes as separate bugs, linked to this one)

Attachments

(4 files)

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.
Attached file input element crash —
Attached file attack of the marquees —
Attached file col span demo (non-crashing) —
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. 
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?
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.
(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
attachment 162506 [details] is causing an nsHTMLUnknownElement to be created whose tag is
nsHTMLAtoms::input.  That shouldn't be able to happen.
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 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.
Attachment #162509 - Attachment description: col span crash → col span demo (non-crashing)
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.
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.
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)
Bleah. Dealing with integer overflow issues in reflow could be a really sticky
nasty mess.
> 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.
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.
(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.

Depends on: 265027
URL is a slightly modified version of the test program.
*** Bug 265091 has been marked as a duplicate of this bug. ***
(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).
*** Bug 265115 has been marked as a duplicate of this bug. ***
> Yeah, right, (1<<31 - 1). :-)

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

/be
Alias: Zalewski
there is another crash (bug 265181) with bogus html when hitting reload on the code.
Depends on: 265181
Depends on: 265068
Depends on: 265067
*** Bug 265247 has been marked as a duplicate of this bug. ***
*** Bug 265294 has been marked as a duplicate of this bug. ***
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).

Summary: Bugtraq "browsers, a mini-farce" crashes → Bugtraq "browsers, a mini-farce" crashes (Zalewski tests)
Depends on: 265404
*** Bug 265519 has been marked as a duplicate of this bug. ***
Depends on: 265583
Depends on: 265585
Keywords: meta
Summary: Bugtraq "browsers, a mini-farce" crashes (Zalewski tests) → Crashes found with Zalewski's mangleme (Bugtraq: "browsers, a mini-farce")
*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.
crasher, but not viewing as file:///. Might work off of bugzilla.
Whiteboard: Please file additional crashes as separate bugs, linked to this one
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.
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.
(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.
..hope I did this right..

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

(bug 265876 per the status whiteboard)
Depends on: 265876
(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).
Depends on: 265892
Depends on: 265846
Depends on: 265947
Depends on: 266015
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.
Blocks: 266966
No longer blocks: 266966
Depends on: 266966
Depends on: 267669
Depends on: 268231
Depends on: 269095
Depends on: 269604
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
  
Product: Browser → Seamonkey
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.
(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.
Depends on: 275912
Depends on: 265857
Blocks: 287681
No longer blocks: 287681
Depends on: 287681
Depends on: 288931
Depends on: 291204
Depends on: 292279
Depends on: 303433
Depends on: 303901
Depends on: 307259
Another, similar fuzz testing tool: http://toadstool.se/software/iexploder/.
(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"
I filed bug 316894 to track bugs found by IExploder.
Blocks: fuzz
Depends on: 317285
Depends on: 320459
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");
Depends on: 323385
Depends on: 323386
Depends on: 323389
Depends on: 325984
Depends on: 328946
Shouldn't this bug be moved to a Core component?
Assignee: general → chofmann
Component: General → Tracking
Product: Mozilla Application Suite → Core
QA Contact: general → chofmann
Whiteboard: Please file additional crashes as separate bugs, linked to this one → [sg:nse meta] Please file additional crashes as separate bugs, linked to this one
Depends on: 338251
Keywords: crash
Summary: Crashes found with Zalewski's mangleme (Bugtraq: "browsers, a mini-farce") → Bugs found with Zalewski's mangleme (Bugtraq: "browsers, a mini-farce")
Works fine
Depends on: 323026
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.