Bug 264944 (Zalewski)

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

RESOLVED INCOMPLETE

Status

Core Graveyard
Tracking
--
critical
RESOLVED INCOMPLETE
13 years ago
11 months ago

People

(Reporter: dveditz, Assigned: chris hofmann)

Tracking

(Blocks: 1 bug, {meta, sec-other})

Trunk
meta, sec-other
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(4 attachments)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
Created attachment 162506 [details]
input element crash
(Reporter)

Comment 2

13 years ago
Created attachment 162508 [details]
attack of the marquees
(Reporter)

Comment 3

13 years ago
Created attachment 162509 [details]
col span demo (non-crashing)
(Assignee)

Comment 4

13 years ago
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. 
(Reporter)

Comment 5

13 years ago
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?
(Reporter)

Comment 6

13 years ago
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.
Depends on: 264956
(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.
attachment 162509 [details] does not crash for me.
(Reporter)

Comment 11

13 years ago
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)

Comment 12

13 years ago
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.
(Reporter)

Comment 13

13 years ago
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

13 years ago
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.

Updated

13 years ago
Depends on: 265027
URL is a slightly modified version of the test program.

Comment 20

13 years ago
*** 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). :-)
> Yeah, right, (1<<31 - 1). :-)

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

/be
(Reporter)

Updated

13 years ago
Alias: Zalewski

Comment 25

13 years ago
there is another crash (bug 265181) with bogus html when hitting reload on the code.
Depends on: 265181
(Reporter)

Updated

13 years ago
Depends on: 265068
(Reporter)

Updated

13 years ago
Depends on: 265067

Comment 26

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

Comment 27

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

Comment 28

13 years ago
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)
(Reporter)

Updated

13 years ago
Depends on: 265404

Comment 29

13 years ago
*** Bug 265519 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

13 years ago
Depends on: 265583
(Reporter)

Updated

13 years ago
Depends on: 265585
Depends on: 265736

Updated

13 years ago
Keywords: meta
Summary: Bugtraq "browsers, a mini-farce" crashes (Zalewski tests) → Crashes found with Zalewski's mangleme (Bugtraq: "browsers, a mini-farce")

Comment 30

13 years ago
*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

13 years ago
Created attachment 163186 [details]
crasher not viewing as a file:///

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

Updated

13 years ago
Whiteboard: Please file additional crashes as separate bugs, linked to this one
(Reporter)

Comment 32

13 years ago
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

13 years ago
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

13 years ago
(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

13 years ago
..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).

Updated

13 years ago
Depends on: 265892

Updated

13 years ago
Depends on: 265846
(Reporter)

Updated

13 years ago
Depends on: 265947

Updated

13 years ago
Depends on: 266015
Depends on: 265867, 265899, 265902, 265973, 265999
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.

Updated

13 years ago
Blocks: 266966

Updated

13 years ago
No longer blocks: 266966
Depends on: 266966

Updated

13 years ago
Depends on: 267669

Updated

13 years ago
Depends on: 268231

Updated

13 years ago
Depends on: 269095

Updated

13 years ago
Depends on: 269604

Comment 38

13 years ago
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

Comment 39

13 years ago
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.

Updated

13 years ago
Depends on: 275912
(Reporter)

Updated

13 years ago
Depends on: 265857

Updated

12 years ago
Blocks: 287681

Updated

12 years ago
No longer blocks: 287681
Depends on: 287681

Updated

12 years ago
Depends on: 288931

Updated

12 years ago
Depends on: 291204

Updated

12 years ago
Depends on: 292279

Updated

12 years ago
Depends on: 299036

Updated

12 years ago
Depends on: 303433

Updated

12 years ago
Depends on: 303901

Updated

12 years ago
Depends on: 307259

Comment 41

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

Comment 42

12 years ago
(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

12 years ago
I filed bug 316894 to track bugs found by IExploder.

Updated

12 years ago
Blocks: 316898

Updated

12 years ago
Depends on: 317285

Updated

12 years ago
Depends on: 320459

Comment 44

12 years ago
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");

Updated

12 years ago
Depends on: 323385

Updated

12 years ago
Depends on: 323386

Updated

12 years ago
Depends on: 323389

Updated

12 years ago
Depends on: 325984

Updated

11 years ago
Depends on: 328946

Comment 45

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

Updated

11 years ago
Assignee: general → chofmann
Component: General → Tracking
Product: Mozilla Application Suite → Core
QA Contact: general → chofmann
(Reporter)

Updated

11 years ago
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

Updated

11 years ago
Depends on: 338251

Updated

11 years ago
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")

Comment 46

9 years ago
Works fine

Updated

8 years ago
Duplicate of this bug: 320928

Updated

8 years ago
Depends on: 323026
Keywords: sec-other

Comment 48

11 months ago
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
Last Resolved: 11 months ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.