Closed Bug 175358 Opened 22 years ago Closed 22 years ago

LiveConnect: crash in free, possibly exploitable

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 183092
Milestone:
mozilla1.3final

People

(Reporter: security-bugs, Assigned: nisheeth_mozilla)

Details

(Whiteboard: [sg:dupe 183092]) 

There is a crash with liveconnect. Reproducible most of the time, though
not 100%. The crash is either in free or in malloc, which is a sign of
corrupted heap and may be exploitable.
--------------------------------------------------
<html>
Written by <a href="http://www.guninski.com">Georgi Guninski</a>

<html>
<script>
var x=new java.net.ServerSocket(1234);
//var x=new java.net.ServerSocket("1234");
alert(x);
</script>
</html>

</html>
--------------------------------------------------



Top of stack:
--------------------------------------------------------
Stack:
nsProfileLock::FatalSignalHandler(int, siginfo *, void *)+0x00000159
[/usr/local/inst/mozilla/mozilla/dist/bin/components/libprofile.so +0x00024651]
UNKNOWN [/lib/i686/libpthread.so.0 +0x00009963]
UNKNOWN [/lib/i686/libc.so.6 +0x0002E840]
__libc_free+0x000000A8 [/lib/i686/libc.so.6 +0x00080BE8]
jni_SecureNewObject(RemoteJNIEnv_ *, _jclass *, _jmethodID *, jvalue *, _jobject
**, nsISecurityContext *)+0x00000152
[/opt/netscape7/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so +0x0002AA16]
CSecureJNIEnv::NewObject(_jclass *, _jmethodID *, jvalue *, _jobject **,
nsISecurityContext *)+0x0000003E
[/opt/netscape7/plugins/java2/plugin/i386/ns600/libjavaplugin_oji.so +0x00019C1E]
ProxyJNIEnv::NewObjectA(JNIEnv_ *, _jclass *, _jmethodID *, jvalue *)+0x00000086
[/usr/local/inst/mozilla/mozilla/dist/bin/components/liboji.so +0x000234DA]
UNKNOWN [/usr/local/inst/mozilla/mozilla/dist/bin/libjsj.so +0x00016BAE]
UNKNOWN [/usr/local/inst/mozilla/mozilla/dist/bin/libjsj.so +0x00016D13]
UNKNOWN [/usr/local/inst/mozilla/mozilla/dist/bin/libjsj.so +0x00016E25]
jsj_JavaConstructorWrapper+0x000000C6
[/usr/local/inst/mozilla/mozilla/dist/bin/libjsj.so +0x00016EFA]
js_Invoke+0x00000D18 [/usr/local/inst/mozilla/mozilla/dist/bin/libmozjs.so
+0x0004A3E4]
js_Interpret+0x000089C7 [/usr/local/inst/mozilla/mozilla/dist/bin/libmozjs.so
+0x00054023]
js_Execute+0x0000036A [/usr/local/inst/mozilla/mozilla/dist/bin/libmozjs.so
+0x0004ABBA]
JS_EvaluateUCScriptForPrincipals+0x00000060
[/usr/local/inst/mozilla/mozilla/dist/bin/libmozjs.so +0x000191EC]
nsJSContext::EvaluateString(nsAString const &, void *, nsIPrincipal *, char
const *, unsigned int, char const *, nsAString &, int *)+0x000005B9
[/usr/local/inst/mozilla/mozilla/dist/bin/components/libjsdom.so +0x00062CAD]
nsScriptLoader::EvaluateScript(nsScriptLoadRequest *, nsAFlatString const
&)+0x000003B5
[/usr/local/inst/mozilla/mozilla/dist/bin/components/libgkcontent.so +0x00512FB9]
nsScriptLoader::ProcessRequest(nsScriptLoadRequest *)+0x000000D1
[/usr/local/inst/mozilla/mozilla/dist/bin/components/libgkcontent.so +0x005128E9]
nsScriptLoader::ProcessScriptElement(nsIDOMHTMLScriptElement *,
nsIScriptLoaderObserver *)+0x00001673
[/usr/local/inst/mozilla/mozilla/dist/bin/components/libgkcontent.so +0x005125DF]
nsHTMLScriptElement::MaybeProcessScript(void)+0x000000E6
[/usr/local/inst/mozilla/mozilla/dist/bin/components/libgkcontent.so +0x002C7626]
nsHTMLScriptElement::SetDocument(nsIDocument *, int, int)+0x00000049
[/usr/local/inst/mozilla/mozilla/dist/bin/components/libgkcontent.so +0x002C6B25]
nsGenericHTMLContainerElement::AppendChildTo(nsIContent *, int, int)+0x000000E8
[/usr/local/inst/mozilla/mozilla/dist/bin/components/libgkcontent.so +0x00289688]
HTMLContentSink::ProcessSCRIPTTag(nsIParserNode const &)+0x00000885
[/usr/local/
....
----------------------------------
Georgi Guninski
Not a blocker. We can't make all corrupted heap crashers blockers unless there's
evidence of exploitability.
Whiteboard: [sg:mustfix]
Over to nisheeth.
Assignee: mstoltz → nisheeth
I just tried this test case 4-5 times on last night's trunk debug build on WinXP
with the Java plug-in version 1.4.0_01 and it worked fine for me.

Sending separate email to Georgi to see if he can reproduce this in the latest
builds...
Status: NEW → ASSIGNED
Georgi does have a Bugzilla account.  I had typed his email address wrong and
thought he didn't.  CCing him.

Georgi, I just tried the test case on this bug 4-5 times on last night's trunk
debug build on WinXP with the Java plug-in version 1.4.0_01 and it worked fine
for me.  Can you reproduce the bug in the latest builds?  If so, please post
some information about your machine setup to the bug.

Thanks!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
today's not my day.  :-) i accidentally resolved this bug.  reopening...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This freezes mozilla 1.3a on linux with jre 1.3.1.
Mozilla does not respond at all after opening the testcase.
Can't test it on latest trunk, because java plugin complains about unresolved
symbol.
Shall check it on windows later today.
I was able to reproduce this on 1.3 alpha with JRE 1.4.1_01.  Have set up the
JRE on my linux box and started a debug build on Linux. Lets see what I find...

Setting platform to Linux...
Status: REOPENED → ASSIGNED
OS: Windows 2000 → Linux
Target Milestone: --- → mozilla1.3final
I just filed bug 192657 for a problem I ran into with testing this on the latest
debug build.  For some reason, the Java plugin isn't loading at Mozilla startup.

Will follow up on this tomorrow...
Depends on: 192657
No longer depends on: 192657
ok, so the problem I'm running into is described in bug 116444.  My mozilla is
compiled with gcc 3.0 which does name mangling of C++ methods differently from
gcc 2.9x.x.  The java plugin was built with the gcc 2.9x.x version and thus
isn't binary compatible with my Mozilla build.

I'm installing the older version of gcc and re-compiling Mozilla...
I seg fault with the following stack on Linux:

#0  0x42073a4c in _int_malloc () from /lib/i686/libc.so.6
#1  0x42073155 in malloc () from /lib/i686/libc.so.6
#2  0x400e923b in PR_Malloc (size=48) at prmem.c:433
#3  0x405908ba in nsMemoryImpl::Alloc (this=0x80cf388, size=48)
    at nsMemoryImpl.cpp:319
#4  0x08086b47 in nsMemory::Alloc (size=48) at nsMemory.cpp:87
#5  0x4050a856 in nsCStringKey::Clone (this=0x88a4278) at nsHashtable.cpp:569
#6  0x40509abf in nsHashtable::Put (this=0x8192c80, aKey=0x88a4278, 
    aData=0x823cf20) at nsHashtable.cpp:213
#7  0x41659a4e in nsStringBundleService::insertIntoCache (this=0x8192c68, 
    aBundle=0x88aa7a0, aHashKey=0xbfffd6bc) at nsStringBundle.cpp:672
#8  0x41659837 in nsStringBundleService::getStringBundle (this=0x8192c68, 
    aURLSpec=0x4220aaa0 "chrome://global/locale/commonDialogs.properties", 
    aResult=0xbfffd7ec) at nsStringBundle.cpp:612
#9  0x41659ad9 in nsStringBundleService::CreateBundle (this=0x8192c68, 
    aURLSpec=0x4220aaa0 "chrome://global/locale/commonDialogs.properties", 
    aResult=0xbfffd7ec) at nsStringBundle.cpp:697
#10 0x421ad10c in GlobalWindowImpl::MakeScriptDialogTitle (this=0x87160d8, 
    aInTitle=@0xbfffd8fc, aOutTitle=@0xbfffd85c) at nsGlobalWindow.cpp:2134
#11 0x421ad4ee in GlobalWindowImpl::Alert (this=0x87160d8, aString=@0x88a4290)
    at nsGlobalWindow.cpp:2177

So, why is it that we can't malloc 48 bytes?
For Comment #10 - my guess is the heap is corrupted.
Nisheeth, for the strange java crashes you may try valgrind -
http://devel-home.kde.org/~sewardj/
From the home page:
-------------------
Valgrind is a GPL'd tool to help you find memory-management problems in your
programs. When a program is run under Valgrind's supervision, all reads and
writes of memory are checked, and calls to malloc/new/free/delete are
intercepted. As a result, Valgrind can detect problems such as:

    * Use of uninitialised memory
    * Reading/writing memory after it has been free'd
    * Reading/writing off the end of malloc'd blocks
    * Reading/writing inappropriate areas on the stack
    * Memory leaks -- where pointers to malloc'd blocks are lost forever
-------------------
Basically it emulates the processor and checks for memory access and can find
problems which don't immediately lead to a crash.

I don't have a debug build with java because of the gcc3.0 problem, but on 1.3a
with java valgrind reports the following before crash:
-------------------------
==5195== Invalid write of size 4
==5195==    at 0x41DCDA59: ???
==5195==    by 0x4051327D: ???
==5195==    by 0x40302213: JavaCalls::call_helper(JavaValue *, methodHandle *,
JavaCallArguments *, Thread *) (in
/opt/netscape7/plugins/java2/lib/i386/client/libjvm.so)
==5195==    by 0x4036070C: os::os_exception_wrapper(void (*)(JavaValue *,
methodHandle *, JavaCallArguments *, Thread *), JavaValue *, methodHandle *,
JavaCallArguments *, Thread *) (in
/opt/netscape7/plugins/java2/lib/i386/client/libjvm.so)
==5195==    Address 0xBFFF9E3C is not stack'd, malloc'd or free'd
==5195==

-------------------------



In case someone tries valgrind, I recommend version 1.9.3 (of 1 Jan 03)
The command for tracing mozilla is 
valgrind --trace-children=yes mozilla

I ran valgrind today and was able to reproduce a double free fairly consistently:

==20250== 
==20250== Invalid free() / delete / delete[]
==20250==    at 0x4016517E: free (vg_clientfuncs.c:182)
==20250==    by 0x48AC4555: jni_SecureNewObject (in
/usr/java/j2re1.4.1_01/plugin/i386/ns610/libjavaplugin_oji.so)
==20250==    by 0x48AB70BD: CSecureJNIEnv::NewObject(_jclass *, _jmethodID *,
jvalue *, _jobject **, nsISecurityContext *) (in
/usr/java/j2re1.4.1_01/plugin/i386/ns610/libjavaplugin_oji.so)
==20250==    by 0x47DD1BB5: ProxyJNIEnv::NewObjectA(JNIEnv_ *, _jclass *,
_jmethodID *, jvalue *) (ProxyJNI.cpp:481)
==20250==    Address 0x52289A94 is 0 bytes inside a block of size 46 free'd
==20250==    at 0x4016517E: free (vg_clientfuncs.c:182)
==20250==    by 0x48AC4535: jni_SecureNewObject (in
/usr/java/j2re1.4.1_01/plugin/i386/ns610/libjavaplugin_oji.so)
==20250==    by 0x48AB70BD: CSecureJNIEnv::NewObject(_jclass *, _jmethodID *,
jvalue *, _jobject **, nsISecurityContext *) (in
/usr/java/j2re1.4.1_01/plugin/i386/ns610/libjavaplugin_oji.so)
==20250==    by 0x47DD1BB5: ProxyJNIEnv::NewObjectA(JNIEnv_ *, _jclass *,
_jmethodID *, jvalue *) (ProxyJNI.cpp:481)
==20250==

The stack here matches up with the stack of the crash posted by Georgi when he
created this bug.  The difference is that he got a crash while I got a valgrind
error and continued program execution.

Unfortunately, the free is happening from within the Java plugin code that I
don't have source code for.  I stepped into ProxyJNIEnv::NewObjectA() and
checked all the parameters it passes when it calls CSecureJNIEnv::NewObject(). 
All the parameters looked good but I couldn't step in any further.

Any ideas on how to debug this further?

A sidenote is that when I ran under valgrind, I got the double free error but
the alert came up eventually.  When I ran without valgrind, I seg faulted.  I
guess valgrind's instrumentation prevents crashing down the road.
Joshua, can you help with this potential security bug?  There's a double free
happening in the Java plugin code that I don't have source code for...
Looks like this is a dup of Bug 183092 - the testcases are almost the same
except for the size of the string.
Probably the problem is in jvm, why not spam more @sun.com ?
Regarding Nisheeth's comment for not crashing sometimes - in the description of
the bug I wrote "Reproducible most of the time, though not 100%". Probably the
heap screws in not very deterministic way.
Also it is strange that only linux is affected.

I reproduced this bug by using mozilla 1.3b (built by gcc3.x) + jre 1.4.2 (built
by gcc3.x) on linux. I will try to reproduce this bug by using mozilla nightly
build and jre 1.4.2 nightly build.

This bug is relate to js module.

I can't reproduce this bug on Solaris.
I go on investigate this bug.


I can't reproduce this bug by using mozilla nightly build and jre 1.4.2 nightly
build.

but after I close the popup dialog (popup by alert) and then reload this page.
the crash that is same to bug #183092 happened!
Joshua, I'm marking this a dupe of bug 183092.  I'll keep working on 183092 on
the mozilla side while you investigate it on the java plugin side...

Thanks for your help!

*** This bug has been marked as a duplicate of 183092 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Whiteboard: [sg:mustfix] → [sg:dupe 183092]
Dupe of public bug, clearing security flag
Group: security
You need to log in before you can comment on or make changes to this bug.