Closed Bug 307259 Opened 15 years ago Closed 15 years ago

Firefox 1.0.6 buffer overflow with hostname of all soft hyphens [@ nsStringBuffer::Realloc] [@ nsCSubstring::Capacity] [@ nsGenericElement::~nsGenericElement]

Categories

(Core :: Networking, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta5

People

(Reporter: tommy, Assigned: dbaron)

References

()

Details

(5 keywords, Whiteboard: [sg:fix])

Crash Data

Attachments

(8 files, 7 obsolete files)

23.23 KB, text/plain
Details
61 bytes, text/html
Details
3.36 KB, patch
darin.moz
: review+
dveditz
: superreview+
Details | Diff | Splinter Review
3.92 KB, patch
darin.moz
: review+
dveditz
: superreview+
Details | Diff | Splinter Review
564 bytes, application/octet-stream
Details
632 bytes, application/x-xpinstall
Details
24.02 KB, patch
darin.moz
: review+
dveditz
: superreview+
Details | Diff | Splinter Review
24.62 KB, text/html
Details
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050416 Epiphany/1.2.8
Build Identifier: 

I have found a format string vulnerability within Firefox 1.0.6 which allows for
arbitrary code execution.

Affect Versions:

Firefox Linux 1.0.6
Firefox Win32 1.0.6
Deer Park Latest Build

Below is a url to reproduce this issue:

http://www.security-protocols.com/firefoxwin32-death.html

If you need any further information, please let me know.

Thanks,

Tom Ferris
Researcher
www.security-protocols.com
Key fingerprint = 0DFA 6275 BA05 0380 DD91  34AD C909 A338 D1AF 5D78

Reproducible: Always

Steps to Reproduce:
Blocks: Zalewski
Corresponds to TB9093897Y.
Hardware: PC → All
Summary: Firefox 1.0.6 Format String → Firefox 1.0.6 Format String [@ nsStringBuffer::Realloc]
Summary: Firefox 1.0.6 Format String [@ nsStringBuffer::Realloc] → Firefox 1.0.6 Format String [@ nsStringBuffer::Realloc] [@ nsCSubstring::Capacity]
Summary: Firefox 1.0.6 Format String [@ nsStringBuffer::Realloc] [@ nsCSubstring::Capacity] → Firefox 1.0.6 Format String [@ nsStringBuffer::Realloc] [@ nsCSubstring::Capacity] [@ nsGenericElement::~nsGenericElement]
So the reason I crash here on Linux is not a format string vulnerability; it's a
buffer overflow.

In particular, the presence of a hostname of all dashes (and a rather long one
at that) causes the NormalizeIDN call in nsStandardURL::BuildNormalizedSpec to
return true but set encHost to the empty string.  This means we append 0 to
approxLen, but later on append the long string of dashes to the buffer instead.
Status: UNCONFIRMED → NEW
Component: General → Networking
Ever confirmed: true
Product: Firefox → Core
Summary: Firefox 1.0.6 Format String [@ nsStringBuffer::Realloc] [@ nsCSubstring::Capacity] [@ nsGenericElement::~nsGenericElement] → Firefox 1.0.6 buffer overflow with hostname of all dashes [@ nsStringBuffer::Realloc] [@ nsCSubstring::Capacity] [@ nsGenericElement::~nsGenericElement]
Version: unspecified → Trunk
Attached patch ugly patch to fix trunk crash (obsolete) — Splinter Review
This fixes the trunk crash for me on Linux.  I'm not sure if it's the right
fix, though.  It may be that a hostname of all dashes should be considered
invalid ACE or whatever it is that makes NormalizeIDN think it can decode it,
in which case NormalizeIDN should return false in this case.  And it might be
safer to do that in either case.  I'm still a bit puzzled by some other things
I saw with the testcase, though -- in particular, that it seemed like an
embedded null got into the string somehow.
This may or may not be the same crash dbaron was working on.
Attachment #195056 - Attachment is obsolete: true
On windows I get completely different stacks.

On 1.0.6 I crash in js_SetProtoOrParent: TB9095338

In Deer Park I crash in operator new, handling a mouse event? TB9094980. The
only mouse event I can think of is the one clicking on the testcase link, but it
seemed to crash quite some time after that.

I'll try with the patch and see.
The testcase in comment 5 doesn't crash when I load it from Bugzilla, but it
does crash if I save it to my desktop and load it from there.
Keywords: crash
Whiteboard: [sg:fix]
The net_ToLowerCase call is also a potential buffer overrun here.
The reason I was confused about the lengths is that it was a long string of soft
hyphens (U+00AD), encoded in UTF-8 as (0xC2 0xAD).  So it wasn't quite the
normalization bug I thought it was, but there's definitely still some sort of
bug here.
Summary: Firefox 1.0.6 buffer overflow with hostname of all dashes [@ nsStringBuffer::Realloc] [@ nsCSubstring::Capacity] [@ nsGenericElement::~nsGenericElement] → Firefox 1.0.6 buffer overflow with hostname of all soft hyphens [@ nsStringBuffer::Realloc] [@ nsCSubstring::Capacity] [@ nsGenericElement::~nsGenericElement]
With the patch I still crash on both trunk and branch with the original
testcase, unfortunately in all kinds of different places on corrupted or freed
objects making it very hard to tell what's gone wrong.
The host-all-hyphens crash is now public:
http://www.security-protocols.com/modules.php?name=News&file=article&sid=2910

I'm not making this bug public immediately because of dveditz' comment 10.
Flags: blocking1.8b5?
Flags: blocking-aviary1.0.7?
With network.enableIDN=true this reproduces easily for me.  With
network.enableIDN=false I do not crash.
Can anyone verify that this issue ONLY works if the hostname is all -'s?  While
this will still be a crash, it won't allow arbitrary code execution.
Wrong, since there's stuff appended to the buffer after the hostname.
*** Bug 307722 has been marked as a duplicate of this bug. ***
*** Bug 307725 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b5?
Flags: blocking1.8b5+
Flags: blocking1.7.12+
Flags: blocking-aviary1.0.7?
Flags: blocking-aviary1.0.7+
Attached patch corrected hack fix (obsolete) — Splinter Review
attachment 195062 [details] [diff] [review] wasn't sufficient, as I pointed out in comment 8, and
actually had other bugs as well.  This ought to be, although it's still not the
right long term fix.  dveditz, could you retest with this one?
Attachment #195062 - Attachment is obsolete: true
Comment on attachment 195421 [details] [diff] [review]
corrected hack fix 

>+            AppendToBuf(buf, i, encHost.get(), mHost.mLen);
>+            i += mHost.mLen;

This can be simplified in both patches to:

+	     i = AppendToBuf(buf, i, encHost.get(), mHost.mLen);
Attached patch hack fixSplinter Review
Attachment #195421 - Attachment is obsolete: true
Attachment #195422 - Attachment is obsolete: true
Attachment #195424 - Flags: superreview?(dveditz)
Attachment #195424 - Flags: review?(darin)
This issue has been assigned the CVE id CAN-2005-2871.
Comment on attachment 195424 [details] [diff] [review]
hack fix

sr=dveditz
This version fixes the remaining memory corruption I was seeing.
Attachment #195424 - Flags: superreview?(dveditz) → superreview+
Blocks: sbb?
OK, removing security-confidential flag since everything in this bug is public.
Group: security
Blocks: 307752
Can we confirm whether enableIDN=false fixes the problem?
Comment on attachment 195424 [details] [diff] [review]
hack fix

r=darin

nit: insert newline between closing bracket and "else"
Attachment #195424 - Flags: review?(darin) → review+
Attachment #195425 - Flags: review+
Attachment #195425 - Flags: approval1.7.12?
Attachment #195425 - Flags: approval-aviary1.0.7?
Looking at the code on the trunk, the "network.enableIDN" pref being false
should always avoid the problematic codepath since gIDN will be null.
Comment on attachment 195424 [details] [diff] [review]
hack fix

Checked in to trunk, 2005-09-09 12:06 -0700.
Would setting network.enableIDN to false be a viable work-around until the bug
is fully fixed?
If so, given the high rating Secunia gives this, should we be advising people to
make that change?
I've tested 1.0.6 with Windows XP, Windows 2000, and Windows 98 and disabling
IDN avoids the crash in the URL testcase.  We should get a XPI out to toggle
this pref.
Yes, you should be able to set enableIDN to false in about:config to workaround
this bug.
This XPI installs a new file in the application default prefs directory that
adds the following default preferences:

pref("app.version", "1.0.6.1");
pref("general.useragent.vendorSub", "1.0.6.1");
pref("network.enableIDN", false);
We are confirming for sure the enableIDN=false fixes it and if so will be
posting the workaround shortly.
We are preparing the announcement to http://www.mozilla.org/security/.  Can
people here assist in verification of the XPI:
   a) Does it set enableIDN=false
   b) Does it bump the about dialog version to 1.0.6.1
   c) Does it prevent the crash as described here.

Thanks!

Mike

(In reply to comment #36)
> We are preparing the announcement to http://www.mozilla.org/security/.  Can
> people here assist in verification of the XPI:
>    a) Does it set enableIDN=false
>    b) Does it bump the about dialog version to 1.0.6.1
>    c) Does it prevent the crash as described here.
> 
> Thanks!
> 
> Mike
> 

a) yes
b) yes
c) yes
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.10) Gecko/20050717
Firefox/1.0.6.1
> 

I can verify that Scott's xpi prevents the crash from the simplified testcase
(when opening the crash.html locally).  As Jessa mentioned, the testcase doesn't
crash (with the default prefs) if you try to open it from this bug, but it when
saved locally.

I tested it with Firefox 1.0.6 on Windows XP and Linux (FC 4).
XPI patches verified on both Firefox and Suite.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6.1
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7.11) Gecko/20050727
With Firefox 1.5b1 two of the prefs no longer exist:
app.version
general.useragent.vendorSub

Therefore applying a the xpi patch DOES properly set pref("network.enableIDN",
false);, but adds and sets the other 2 version related prefs (which are no
longer used), so the version bump doesn't happen as expected. 

If we plan to patch Beta 1, we'll have to figure out what the new version prefs
are and create a separate patch.
Keywords: testcase
Here's an updated XPI file which doesn't change the version string at all.

Instead if just adds a No IDN vendor comment. This allows us to use the same
XPI for the suite and for any 1.0.x version of Firefox and the 1.5 beta.
Attachment #195447 - Attachment is obsolete: true
Attachment #195452 - Attachment is obsolete: true
XPI patch v2 looks good. But its comment should be more descriptive.

- pref("general.useragent.vendorComment", "No IDN");
+ pref("general.useragent.vendorComment", "IDN support is disabled for security
reasons. See Bug 307259 for details.");
Sorry, "general.useragent.vendorComment" should be a few simple words.
Ignore my comment above.
New patch works for me on 1.0.6
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.10) Gecko/20050717
Firefox/1.0.6

However on 1.5 Beta 1 it does not seem to show the vendor comment in Help >
About, although the modified preference is correct in about:config
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Also, if you have the ActiveX plugin installed, that sets a vendor comment of
(ax) which (for me) overrode the No IDN vendor commment in 1.0.6
P.S. on Deer Park it did still successfully disable IDN and so did apply the
workaround (it survuded the testcase) - I just didn't get the vendor comment
This updated XPI sets the product comment instead of the vendor comment. 

The vendor comment did not show up on mozilla suite and firefox 1.5b1 because
those  products don't have vendorSub strings. By moving to the productComment
we think the  No IDN text will show up on all 3 of those builds.
Attachment #195467 - Attachment is obsolete: true
The latest XPI works for me on FF 1.0.6 / WinXP: enableIDN is properly set to
false, the text "(No IDN)" appears after "Gecko/20050716" in the UA string, and
the crash is gone.
So we're going to try using the general.useragent.productComment pref. Not
ideal because some UA sniffers might not be expecting a comment string between
the Gecko and Firefox tokens (they are more tolerant of end garbage), but will
work on all Gecko-based browsers. Keep in mind that we will be issuing an actual
patched build in the near future, and then this whole comment thing goes away.
Survives testcase and adds No IDN product comment in my installs of both FF
1.0.6 and FF 1.5 Beta 1

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.10) Gecko/20050717 (No
IDN) Firefox/1.0.6 (ax)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 (No
IDN) Firefox/1.4
I have verified the patch from comment #47 works for:

FF106: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
(No IDN) Firefox/1.0.6
FF15b1: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908
(No IDN) Firefox/1.4
M1711: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
(No IDN)

All three have their network.enableIDN=false and are crash free.
Looks good on Mac, both FF 1.0.6 and FF 1.5b1. The No IDN text appears in the
about firefox and the enable IDN is set to false.
and looks good in the Mozilla suite as well, forgot to add that - Mozilla 1.7.11
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727
(No IDN)

(In reply to comment #52)
> Looks good on Mac, both FF 1.0.6 and FF 1.5b1. The No IDN text appears in the
> about firefox and the enable IDN is set to false.
No longer blocks: 307752
Comment on attachment 195424 [details] [diff] [review]
hack fix

approving for 1.8b5
Attachment #195424 - Flags: approval1.8b5? → approval1.8b5+
Comment on attachment 195425 [details] [diff] [review]
aviary branch version of hack fix

sr=dveditz
a=dveditz for aviary and 1.7 branches
Attachment #195425 - Flags: superreview+
Attachment #195425 - Flags: approval1.7.12?
Attachment #195425 - Flags: approval1.7.12+
Attachment #195425 - Flags: approval-aviary1.0.7?
Attachment #195425 - Flags: approval-aviary1.0.7+
*** Bug 307800 has been marked as a duplicate of this bug. ***
Firefox 1.5 beta 1 should be patched via the new app update system.  There's no
reason to cut an XPI for it.  For the update to 1.5 beta 1 (is it going to be
1.4.1 or 1.4.0.1?), we should just take dbaron's patch and not futz with the
enableIDN pref.
(In reply to comment #57)
> Firefox 1.5 beta 1 should be patched via the new app update system.  There's no
> reason to cut an XPI for it.  For the update to 1.5 beta 1 (is it going to be
> 1.4.1 or 1.4.0.1?), we should just take dbaron's patch and not futz with the
> enableIDN pref.

1.5 should and most likely will be patched with the update system (what a great
opportunity to test it!), but we're not going to build/test/push over the
weekend. For users who see the press over the weekend it's nice to have an easy
patch for them. We'll make sure the next version's installers removes the pref file.

I know the patch system can remove files... will it fail if the file is not
there to remove? that is, some number of users will have the file to be removed,
but most will not. If removing a non-existing file causes problems then it's
better not to mess with it.
This is SA16764 at http://secunia.com/advisories/16764/ and FrSIRT/ADV-2005-1690
at http://www.frsirt.com/english/advisories/2005/1690 (both rated as Critical).
Is there a change to update Alias field to SA16764 etc.
Information about new http://www.mozilla.org/security/idn.html page spreaded
with Internet Storm Center, MozillaZine etc.
attachment 195424 [details] [diff] [review] checked in to trunk, 2005-09-09 12:06 -0700.
attachment 195425 [details] [diff] [review] checked in to AVIARY_1_0_1_20050124_BRANCH, 2005-09-09 16:33
-0700.
attachment 195425 [details] [diff] [review] checked in to MOZILLA_1_7_BRANCH, 2005-09-09 16:34 -0700.
attachment 195424 [details] [diff] [review] checked in to MOZILLA_1_8_BRANCH, 2005-09-10 00:12 -0700.
Assignee: nobody → dbaron
Keywords: fixed1.8
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta5
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
[10 12:33:56] <rob_strong> JAY: looks like the 307259.xpi was packaged with
incorrect perms for Linux
...
[10 12:39:45] <dbaron> rob_strong, do you mean that the permissions inside the
XPI are wrong?
[10 12:41:39] <rob_strong> dbaron: yes
[10 12:42:16] <rob_strong> dbaron: same as happened last time iirc
[10 12:42:54] <dbaron> what are they, and what should they be?
[10 12:43:06] <rob_strong> they are  400
[10 12:43:29] <rob_strong> They should be +r for all
[10 12:45:05] <rob_strong> Here is a handy py script for verifying
http://biomikro.vscht.cz/maldiman/hassmanm/projects/testzip.py.txt
[10 12:51:43] <dbaron> mind if I paste this in the bug?
[10 12:52:26] <rob_strong> Not at all
for what it is worth the files in this xpi are the same as on the mirrors but
have been packaged with perms set to 0644.
Rather than figure out whether we really need this, I propose we take this as
well.

I also changed two function names that are dangerously unclear.
Attachment #195682 - Flags: superreview?(dveditz)
Attachment #195682 - Flags: review?(darin)
The SetQuery and SetRef changes in that patch aren't quite right, though...
Actually, I think they're OK, since they match what BuildNormalizedSpec does.
Flags: blocking1.7.13+
Flags: blocking1.7.12+
Flags: blocking-aviary1.0.8+
Flags: blocking-aviary1.0.7+
Attachment #195682 - Flags: approval1.8b5?
Attachment #195682 - Flags: approval1.7.12?
Attachment #195682 - Flags: approval-aviary1.0.7?
Comment on attachment 195682 [details] [diff] [review]
belt-and-braces patch

sr=dveditz
Attachment #195682 - Flags: superreview?(dveditz) → superreview+
Does the belt-and-braces patch contribute to fix this specific problem or is
this  just a preventive measure like the name 'belt-and-braces' suggests? 

If so, I would rather suggest to not send this patch to the aviary branch. Would
be great to keep the changeset minimal for the stable branch.
It appears that the 307259.xpi on the mirrors is still the one with bad perms
for unix... :/
Comment on attachment 195682 [details] [diff] [review]
belt-and-braces patch

It almost seems to me that a small helper class that combines a
string object with a boolean flag would be nice here.


>Index: nsStandardURL.cpp

>+    EncodeSegmentCount(str.BeginReading(text), URLSegment(0, str.Length()), mask, result, encoded);
>+    if (encoded)
>         return result;
>     else
>         return str;
> }

I know this isn't your code, but if you would, please change that to this:

   return encoded ? result : str;

Or, at least remove the unnecessary 'else'.  thanks!


r=darin
Attachment #195682 - Flags: review?(darin) → review+
Will this bug alone cause a 1.0.7 release? Or will there be a waiting period in
case there are more? I see it is marked blocking, but how urgent is it? Thanks
for the quick fix.
(In reply to comment #69)
> It appears that the 307259.xpi on the mirrors is still the one with bad perms
> for unix... :/

ftp-chi.osuosl.org was the odd-one-out when I checked all the md5sums.  Everyone
else had the correct version.  I contacted the admin, and it's probably been
fixed already by the time I'm typing this.
(In reply to comment #72)
> ftp-chi.osuosl.org was the odd-one-out when I checked all the md5sums.  Everyone
> else had the correct version.  I contacted the admin, and it's probably been
> fixed already by the time I'm typing this.
Are you sure? I checked on a couple of the mirrors and they aren't fixed for me.
I also checked using the python script (
http://biomikro.vscht.cz/maldiman/hassmanm/projects/testzip.py.txt ) which shows
they are packaged with 400 perms and the dates are from the 9th which is before
the permissions issue was brought up on 20050910.
http://mozilla.ussg.indiana.edu/pub/mozilla.org/firefox/releases/1.0.6/patches/
http://149.174.36.116/pub/mozilla.org/firefox/releases/1.0.6/patches/
Attachment #195682 - Flags: approval1.8b5?
Attachment #195682 - Flags: approval1.8b5+
Attachment #195682 - Flags: approval1.7.12?
Attachment #195682 - Flags: approval1.7.12+
Attachment #195682 - Flags: approval-aviary1.0.7?
Attachment #195682 - Flags: approval-aviary1.0.7+
attachment 195682 [details] [diff] [review] checked in:
 * to trunk, 2005-09-13 10:38 -0700
 * to MOZILLA_1_8_BRANCH, 2005-09-13 11:23 -0700
attachment 195682 [details] [diff] [review] excluding the renames of functions (which didn't exist on the
old branches) checked in:
 * to AVIARY_1_0_1_20050124_BRANCH, 2005-09-13 11:23 -0700
 * to MOZILLA_1_7_BRANCH, 2005-09-13 11:24 -0700
(In reply to comment #73)
> (In reply to comment #72)
> > ftp-chi.osuosl.org was the odd-one-out when I checked all the md5sums.
> > Everyone else had the correct version.  I contacted the admin, and it's
> > probably been fixed already by the time I'm typing this.
> Are you sure? I checked on a couple of the mirrors and they aren't fixed for
> me.

All 17 servers match md5sums now, and all have the same md5sum as stage.  If
it's wrong, then they're all wrong, and the correct xpi apparently hasn't been
uploaded yet.
Correct... at least now the xpi with the incorrect file permissions for UNIX is
properly distributed to all the mirrors. :P

I verified using the py script and by installing the patch that it does indeed
have no access set for everyone except root when installed as root so the patch
is not applied to anyone but the root account (e.g. no access means it isn't
read by the pref system since it can't access it). See bug 189905 for details as
to the underlying details.
Well that's not good at all. dbaron: if you can take a quick look at this and
make sure that Rob's update works as expected, I can push it to the ftp site. Do
we need to go further with this, or just post the xpi with correct permissions
and push on to 1.0.7?
did someone actually push the xpi with permission bits set for linux over the
weekend or did the xpi just get posted to this bug? I'm more than happy to
upload the new version. I thought someone had already done so. 
According to stage, the xpi hasn't been modified since September 9th (Rob's
patch was posted on the 10th for those following along at home). This seems like
another one of those "someone will get it" situations... Scott: are you going to
post the xpi, or should I go ahead and do it? 
If there is anything I can do to help just ask... also, it might not be such a
bad idea to run the python script on any future xpi based patches to verify the
perms. This is the second time this has happened out of the two or three times
xpi patches have been pushed in the last year.
(In reply to comment #77)
> Well that's not good at all. dbaron: if you can take a quick look at this and
> make sure that Rob's update works as expected, I can push it to the ftp site. Do
> we need to go further with this, or just post the xpi with correct permissions
> and push on to 1.0.7?

I've pushed dbaron's updated XPI to the FTP site.  Here are the MD5 checksums
for the 307259.xpi file:

Old 307259.xpi: d3d1c4d2dac9b90143574ca7e2fa8330
New 307259.xpi: c58d917c5dab7bbd18ec9807485cb7d4
(In reply to comment #83)
> FYI:
> 
> http://security-protocols.com/modules.php?name=News&file=article&sid=2920(In
> reply to comment #82)
> > FYI:
> > 
> > http://security-protocols.com/modules.php?name=News&file=article&sid=2920
> 
> almost forget the PoC:
> 
> http://www.security-protocols.com/deerpark-death.html

What does that crash bug (in 1.5b1 only) have to do with this bug?

/be
(In reply to comment #82)
> FYI:
> 
> http://security-protocols.com/modules.php?name=News&file=article&sid=2920

Filed bug 308579 on the new crash. It's a completely unrelated null dereference
despite the superficial similarity in the testcase.

(In reply to comment #85)
> (In reply to comment #82)
> > FYI:
> > 
> > http://security-protocols.com/modules.php?name=News&file=article&sid=2920
> 
> Filed bug 308579 on the new crash. It's a completely unrelated null dereference
> despite the superficial similarity in the testcase.

Tom Ferris: your public statements on this matter of fact are incorrect and
misleading.  What are you going to do about that?

/be
ff 1.0.6/winxp: URL->crash, simplified->no crash, firefoxwin32-death->crash
ff 1.0.7/winxp; ff 1.5/winxp (20050914) no crash.
The contents at the testcase link in comment 0 have been changed to Jesse's
simplified testcase from comment 5. Just for the record this is the original
testcase from Tom Ferris.
Blocks: sbb+
No longer blocks: sbb?
no crash firefox 1.5 rc2 winxp/linux
Keywords: fixed1.8verified1.8
Comment on attachment 195425 [details] [diff] [review]
aviary branch version of hack fix

Clearing aviary1.0.8/1.7.13 approval flags on this attachment because attachment 195682 [details] [diff] [review] is already in.
Attachment #195425 - Flags: approval1.7.13+
Attachment #195425 - Flags: approval-aviary1.0.8+
Are crashtests appropriate Is or wanted for this? Would they live in netwerk/base/src/crashtests ?
Crash Signature: [@ nsStringBuffer::Realloc] [@ nsCSubstring::Capacity] [@ nsGenericElement::~nsGenericElement]
You need to log in before you can comment on or make changes to this bug.