141375 - Crash with long IRC: URLs

Status: RESOLVED DUPLICATE of bug 94448

(Core :: Security, defect)

Description

[Ben Bucksch (:BenB)]

<quote
src="ttp://online.securityfocus.com/archive/1/270249/2002-04-27/2002-05-03/0">
The IRC:// protocol inhibited by Mozilla/NS6 seems to have a buffer overrun.
A typical IRC URL could look like this:

IRC://IRC.YOUR.TLD/#YOURCHANNEL

The #YOURCHANNEL part is copied to a buffer that has a limit of 32K. 
If the input exceeds this limit, Mozilla 1.0 RC1 crashes with the following
error: 

The exception unknown software exception (0xc00000fd) occured in the
application at location 0x60e42edf 

Mozilla 0.9.9 gives a similar exception: 

The exception unknown software exception (0xc00000fd) occured in the
application at location 0x60dd2c79.

Other versions of Mozilla/NS6/Galeon likely share the same flaw.
I haven't tested further on how practically exploitable this is.
Short example online at

http://jscript.dk/2002/4/moz1rc1tests/ircbufferoverrun.html
</quote>

Will attach testcase. I inserted a "#" after the hostpart, e.g.
<irc://www.mozilla.org/#AAAA...>, while the original testcase had none, e.g.
<irc://www.mozilla.org/AAAA...>.

I could not reproduce it on Linux, but on Windows 2000.

Talkback-ID TB5795435W.

Comment 1

[James Cox]

adding some cc's.

Comment 2

[Boris Zbarsky [:bzbarsky]]

The IRC protocol handler is implemented in javascript, so it doesn't allocate
any buffers of its own really....  The likely suspects are probably JS engine
and nsStandardURL....

Comment 3

[Robert Ginda]

I believe the problem is related to chatzilla trying to display the url.  A xul
file with a <label> in it with 64k characters crashes mozilla on unix, at least.
   It crashes more than mozilla, in fact, it hangs the entire X server.

I'd be willing to bet there is more than one problem here too.  In addition to
feeding the X server too much data, when chatzilla trys to "munge" the text for
display, something like bug 94448 might be happening.

Comment 4

[Robert Ginda]

Attachment: xul testcase (this will crash your X server!)

Don't try this on unix unless you've saved everything.	It brings down all of X
on my system.  Havn't tried it out on windows.

The file is a single XUL <label>, with a value attribute of 64k "A" characters.

Comment 5

[Ben Bucksch (:BenB)]

adjusting summary to reflect suspected cause and new testcase.

Comment 6

[Ben Bucksch (:BenB)]

Attachment: irc url scheme testcase

Strangly, rginda's textcase does not crash for me on Windows.

Comment 7

[Joseph Elwell]

From talkback.

Stack Signature  matchRENodes f9fbafb7
Product ID MozillaTrunk
Build ID 2002043010
Trigger Time 2002-04-30 23:56:48
Platform Win32
Operating System Windows NT 5.0 build 2195
Module js3250.dll
URL visited http://bugzilla.mozilla.org/show_bug.cgi?id=141375
User Comments
Trigger Reason Stack overflow
Source File Name jsregexp.c
Trigger Line No. 1807
Stack Trace
matchRENodes [jsregexp.c, line 1807]
greedyRecurse [jsregexp.c, line 1471]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489]
greedyRecurse [jsregexp.c, line 1489] 

Comment 8

[Ben Bucksch (:BenB)]

Attachment: irc url scheme testcase

The previous testcase has a wrong label (inherited from the original testcase).
Fixing that (hopefully).

Comment 9

[Ben Bucksch (:BenB)]

rginda's testcase doesn't crash for me on linux either.

Comment 10

[Bradley Baetz (:bbaetz)]

These test cases don't crash for me either.

The irc url one has a wierd highliting effect, though, where about 1 in every
3-4 lines are black, and the rest are the standard grey hilite color for
inactive-select.

Is this an X thing, maybe? I'm running XFree86-4.1.0-15. That wouldn't explain
the windows crash, though.

ccing brendan and and shaver. That stack looks like greedyRecurse may be too
greedy. Theres some #ifdef XP_MAC code to catch this, presumably due to the
mac's low stack limit. Linux/window's limit may be higher, but surely there
should still be some sort of limit?

Comment 11

[Bradley Baetz (:bbaetz)]

So, if I try this in q build which actually has chatzilla installed, it hangs. I
got sick of it hanging, so I convinced gdb to attach to hit. Here are the bottom
frames:

#23273 0x400caba1 in greedyRecurse (grState=0xbfffe0c0, cp=0x8b90a4e, 
    previousKid=0x8b90a4c) at /home/bbaetz/src/mozilla/js/src/jsregexp.c:1488
#23274 0x400caba1 in greedyRecurse (grState=0xbfffe0c0, cp=0x8b90a4c, 
    previousKid=0x8b90a4a) at /home/bbaetz/src/mozilla/js/src/jsregexp.c:1488
#23275 0x400caba1 in greedyRecurse (grState=0xbfffe0c0, cp=0x8b90a4a, 
    previousKid=0x8b90a48) at /home/bbaetz/src/mozilla/js/src/jsregexp.c:1488
#23276 0x400caba1 in greedyRecurse (grState=0xbfffe0c0, cp=0x8b90a48, 
    previousKid=0x8b90a46) at /home/bbaetz/src/mozilla/js/src/jsregexp.c:1488
#23277 0x400caba1 in greedyRecurse (grState=0xbfffe0c0, cp=0x8b90a46, 
    previousKid=0x8b90a44) at /home/bbaetz/src/mozilla/js/src/jsregexp.c:1488
#23278 0x400cac38 in matchGreedyKid (state=0xbfffe220, ren=0x8aab6f0, 
    stop=0x0, kidCount=1, cp=0x8b90a46, previousKid=0x8b90a44)
    at /home/bbaetz/src/mozilla/js/src/jsregexp.c:1518
#23279 0x400cbe41 in matchRENodes (state=0xbfffe220, ren=0x8aab6f0, stop=0x0, 
    cp=0x8b90a44) at /home/bbaetz/src/mozilla/js/src/jsregexp.c:1865
#23280 0x400cbd14 in matchRENodes (state=0xbfffe220, ren=0x8aab780, stop=0x0, 
    cp=0x8b90a44) at /home/bbaetz/src/mozilla/js/src/jsregexp.c:1824
#23281 0x400cc7d5 in MatchRegExp (state=0xbfffe220, ren=0x8aab858, 
    cp=0x8b8f268) at /home/bbaetz/src/mozilla/js/src/jsregexp.c:2144
#23282 0x400cc977 in js_ExecuteRegExp (cx=0x89445d8, re=0x8aab8b8, 
    str=0x8b44c80, indexp=0xbfffe2a8, test=0, rval=0xbfffe3b0)
    at /home/bbaetz/src/mozilla/js/src/jsregexp.c:2213
---Type <return> to continue, or q <return> to quit---
#23283 0x400d67bf in match_or_replace (cx=0x89445d8, obj=0x8b44ca8, argc=1, 
    argv=0x8b6afc4, glob=0x400d67e8 <match_glob>, data=0xbfffe2e0, 
    rval=0xbfffe3b0, forceFlat=0)
    at /home/bbaetz/src/mozilla/js/src/jsstr.c:1117
#23284 0x400d68e0 in str_match (cx=0x89445d8, obj=0x8b44ca8, argc=1, 
    argv=0x8b6afc4, rval=0xbfffe3b0)
#23285 0x4009fa44 in js_Invoke (cx=0x89445d8, argc=1, flags=0)
    at /home/bbaetz/src/mozilla/js/src/jsinterp.c:788
#23286 0x400aa561 in js_Interpret (cx=0x89445d8, result=0xbfffe6bc)
    at /home/bbaetz/src/mozilla/js/src/jsinterp.c:2743
#23287 0x4009faaf in js_Invoke (cx=0x89445d8, argc=2, flags=0)
    at /home/bbaetz/src/mozilla/js/src/jsinterp.c:805
#23288 0x400aa561 in js_Interpret (cx=0x89445d8, result=0xbfffeac0)
    at /home/bbaetz/src/mozilla/js/src/jsinterp.c:2743
#23289 0x4009ff87 in js_Execute (cx=0x89445d8, chain=0x8572540, 
    script=0x88db6d0, down=0x0, special=0, result=0xbfffeac0)
    at /home/bbaetz/src/mozilla/js/src/jsinterp.c:968
#23290 0x4007de98 in JS_EvaluateUCScriptForPrincipals (cx=0x89445d8, 
    obj=0x8572540, principals=0x816ad84, chars=0x88fe830, length=10, 
    filename=0x8b6f408 "chrome://chatzilla/content/static.js", lineno=858, 
    rval=0xbfffeac0) at /home/bbaetz/src/mozilla/js/src/jsapi.c:3363
#23291 0x4136b9a2 in nsJSContext::EvaluateString (this=0x8a692a8, 
---Type <return> to continue, or q <return> to quit---
    aScript=@0xbfffecf0, aScopeObject=0x8572540, aPrincipal=0x816ad80, 
    aURL=0x8b6f408 "chrome://chatzilla/content/static.js", aLineNo=858, 
    aVersion=0x400e3476 "default", aRetValue=@0xbfffed00, 
    aIsUndefined=0xbfffec98)
    at ../../../dist/include/string/nsPromiseFlatString.h:165
#23292 0x4138edaf in GlobalWindowImpl::RunTimeout (this=0x89a4738, 
    aTimeout=0x8abc6f0) at ../../../dist/include/xpcom/nsCOMPtr.h:650
#23293 0x4138fef9 in GlobalWindowImpl::TimerCallback (aTimer=0x854b288, 
    aClosure=0x8abc6f0)
    at /home/bbaetz/src/mozilla/dom/src/base/nsGlobalWindow.cpp:4841
#23294 0x401c7d9e in nsTimerImpl::Fire (this=0x854b288)
    at /home/bbaetz/src/mozilla/xpcom/threads/nsTimerImpl.cpp:344
#23295 0x401c8107 in handleTimerEvent (event=0x8a6e8e8)
    at /home/bbaetz/src/mozilla/xpcom/threads/nsTimerImpl.cpp:406
#23296 0x401bf5b7 in PL_HandleEvent (self=0x8a6e8e8)
    at /home/bbaetz/src/mozilla/xpcom/threads/plevent.c:596
#23297 0x401bf417 in PL_ProcessPendingEvents (self=0x80ca908)
    at /home/bbaetz/src/mozilla/xpcom/threads/plevent.c:526
#23298 0x401c1552 in nsEventQueueImpl::ProcessPendingEvents (this=0x80f2880)
    at /home/bbaetz/src/mozilla/xpcom/threads/nsEventQueue.cpp:388
#23299 0x409e49fa in event_processor_callback (data=0x80f2880, source=4, 
    condition=GDK_INPUT_READ)
    at /home/bbaetz/src/mozilla/widget/src/gtk/nsAppShell.cpp:184
---Type <return> to continue, or q <return> to quit---
#23300 0x409e4658 in our_gdk_io_invoke (source=0x42001880, condition=G_IO_IN, 
    data=0x42001870)
    at /home/bbaetz/src/mozilla/widget/src/gtk/nsAppShell.cpp:77
#23301 0x40430f9e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#23302 0x40432773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#23303 0x40432d39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#23304 0x40432eec in g_main_run () from /usr/lib/libglib-1.2.so.0
#23305 0x4034d333 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#23306 0x409e5515 in nsAppShell::Run (this=0x814e000)
    at /home/bbaetz/src/mozilla/widget/src/gtk/nsAppShell.cpp:364
#23307 0x409a32f9 in nsAppShellService::Run (this=0x813eeb0)
    at ../../../dist/include/xpcom/nsCOMPtr.h:650
#23308 0x080590ef in main1 (argc=1, argv=0xbffff634, nativeApp=0x8093950)
    at ../../dist/include/xpcom/nsCOMPtr.h:650
#23309 0x08059d71 in main (argc=1, argv=0xbffff634)
    at /home/bbaetz/src/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1779
#23310 0x40591647 in __libc_start_main (main=0x8059be0 <main>, argc=1, 
    ubp_av=0xbffff634, init=0x804e384 <_init>, fini=0x805d1bc <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff62c)
    at ../sysdeps/generic/libc-start.c:129

The remaining 23,000 odd frames are greedyRecurse, with the cp value increasing
as we go up the stack. I suppose this will eventually cause a stack overflow,
but I don't know if its exploitable.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

As a workaround until a real fix is found, could this be fixed by disabling
chatzilla by default?

Comment 13

[Bradley Baetz (:bbaetz)]

Is this a security bug? shaver on #mozilla thinks not.

Anyway, I suspect that whats happening is that we're maching against this 64K
string one character at a time, recursively. I'd love to know what the regexp
actually is, though.

Comment 14

[Mike Shaver (:shaver emeritus)]

I don't think we need to worry about chatzilla here: any content author can whip
up a huge string and feed it to a regexp, and then we'll crash.  This doesn't
look exploitable to me -- it's "just" an excessive-recursion stack-blowing DoS,
with no user-supplied data on the stack, and we have more than a few of those
already (including a few in the JS engine).  Mitch may have another opinion of
this, though, if I'm missing something.

This really does look like a straight-up dup of 94448, at least the part that
bbaetz coughed up a stack for.

Comment 15

[James Cox]

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

Comment 16

[Robert Ginda]

Simple *viewing* Bug 141692 crashes my X server.

[rginda_l@thinkpad rginda_l]$ X -version

XFree86 Version 4.1.0 (Red Hat Linux release: 4.1.0-3) / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: 2 June 2001
        If the server is older than 6-12 months, or if your card is
        newer than the above date, look for a newer version before
        reporting problems.  (See http://www.XFree86.Org/FAQ)
Build Operating System: Linux 2.4.7-0.13.1smp i686 [ELF] 
Build Host: stripples.devel.redhat.com
 
Module Loader present

Comment 17

[Matthias Versen [:Matti]]

is bug 140055 releated to this one ?

Comment 18

[Ben Bucksch (:BenB)]

Comment on attachment 81831 [details]
xul testcase (this will crash your X server!)

I filed bug 141854 about rginda's reports for a crashing X server, as I think
that this is a different problem.

Comment 19

[Mitchell Stoltz (not reading bugmail)]

Changing summary, marking dupe.

*** This bug has been marked as a duplicate of 94448 ***