305453 - Crash with sockets [@ nsSocketTransport::Release]

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Steven]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Working with Javascript/XUL Sockets (Using lzSocket class for test-case)
lzSocket Information: http://lezardilla.mozdev.org/docs/node11.html
js file: http://www.mozdev.org/source/browse/lezardilla/src/lzSocket.js

Firefox crashes after retrieving data from host.

Reproducible: Always

Steps to Reproduce:
1. Create a HTML page with lzSocket js file (
http://www.mozdev.org/source/browse/lezardilla/src/lzSocket.js )
2. Create javascript to call functions outlined in above file. Such as the
following:
function jss(ip,port) {
	var socket = new lzSocket();

    socket.open(ip,port);

	var out = "GET / HTTP/1.1\r\n";
	out += "Host: 127.0.0.1\r\n";
	out += "Connection: Close\r\n\r\n";
	socket.write(out);

	var response = socket.read();

	alert(response);

    socket.close();
}
3. Enable "signed.applets.codebase_principal_support" in prefs in order to allow
connection, as outlined here:
http://www.mozilla.org/projects/security/components/jssec.html#codebase
4. Run above javascript. Example: jss('207.126.111.226','80');
Actual Results:  
The function succesfully returns all data, but then Firefox crashes.

Expected Results:  
Simply return all received data, and return to normal state.

Debug with Microsoft Visual C++ Returns:
Unhandeled exception in firefox.exe: 0xC0000005: Access Violation

Comment 1

[timeless]

please install talkback and provide a talkback incident id.

Comment 2

[Steven]

(In reply to comment #1)
> please install talkback and provide a talkback incident id.

Sorry about that.

Incident ID: 8588033
Link:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=8588033

This is my original submission, and the details in the 'User Comments' aren't
completely correct (did alot more investigating before I submitted this bug,
after that incident was submitted).

Comment 3

[Martijn Wargers (dead)]

Stack from comment 2:
nsSocketTransport::Release 
[c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsSocketTransport2.cpp,
line 1479]
nsHttpConnection::Activate 
[c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnection.cpp,
line 130]
nsHttpConnectionMgr::DispatchTransaction 
[c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp,
line 569]
nsHttpConnectionMgr::ProcessNewTransaction 
[c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp,
line 698]
nsHttpConnectionMgr::OnMsgNewTransaction 
[c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp,
line 726]

Is this also an issue with the current nightly trunk build?
http://mozilla.isc.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 4

[Steven]

(In reply to comment #3)
> Is this also an issue with the current nightly trunk build?
> http://mozilla.isc.org/pub/mozilla.org/firefox/nightly/latest-trunk/

The latest nightly build is not even able to make the connection.
The following errors are returned (via alert windows):

'Exception while opening socket:TypeError: this.TransportService.init is not a
function'
'Unable to write in stream socket: TypeError: this.outputStream has no properties'
'Error while reading socket:
[Exception... "Component returned failure code: 0xc1f30001
(NS_ERROR_NOT_INITIALIZED) [nsIScriptableInputStream.available]" nsresult:
"0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame ::
http://localhost/sockets.html :: anonymous :: line183" data: no]'
'null'

There was not a crash the first time I tried this. After trying it again (in
order to write out the above alert windows) Deer Park Alpha 2 Crashes with the
same return:
Unhandeled exception in firefox.exe: 0xC0000005: Access Violation.

Incident ID: 8611852
Link:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=8611852

Comment 5

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

   this.transportService  =
Components.classes["@mozilla.org/network/socket-transport-service;1"].createInstance(Components.interfaces.nsISocketTransportService);

it's a service - you must use getService, not createInstance!

does it work with that change?

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase

This is more or less copied from the reporter.
The error in comment 4 happens because of the fix for bug 283049.
Removing  this.transportService.init(); makes it work again.

The testcase needs to be opened locally.
It crashes for me on reload. Talkback ID: TB8631327X
The suggestion in comment 5 works and makes the testcase not crash on reload.

Comment 7

[Steven]

(Sorry for delayed reply)

After changing to getService as reccommended in comment #5, the script did
function without a crash (Firefox 1.0.6), but it did not run without issues.
After running the said script, Firefox starts exibiting a odd behavior in which
it refuses to load any pages. Any links (Bookmarks, Refresh/Home Buttons,
anything) do not actually change the page; it stays. Very odd behavior.

With the latest nightly trunk:
The same errors are returned as outlined in comment #4, but no longer crashes
(thankfully).

Hopefully this can be sorted out before FF 1.5 B1

Comment 8

[Steven]

Oops. I kind of completely ignored comment #6, sorry. My mistake.

With the changes specified in comment #6 (removing
this.transportService.init();), it works in the latest trunk. Although FF 1.0.6
still exhibits the odd behavior as described in comment #7, I think I can live
with it until 1.5

Everything seems to be working perfectly. Sorry for the mix-up.

Although, it would be nice if using createInstance simply returned a error
instead of crashing. Would be nice to have that sorted.

Thanks for your time.

Comment 9

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

you should also remove the .shutdown call, that probably fixes the 1.0.x issues.

in lzSocket.js:
      this._connected==false;

I think you mean =, not ==


What's the purpose of your wait() function if you have a blocking input stream?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Not a bug; just misuse of a contract.

Comment 11

[Martijn Wargers (dead)]

But should the misuse of a contract cause a crash then?
Shouldn't you get an error message or something like that, instead?

Comment 12

[Boris Zbarsky [:bzbarsky]]

There's no way to detect it, really.

Comment 13

[timeless]

actually we can fix the generic cosntructor macros to cause this not to mess up.

Comment 14

[Darin Fisher]

Yeah, that's true.  Patches welcome.

Comment 15

[Chris Lawson (gone)]

Confirming per comment 13 and comment 14, since there's something that can be patched here.

Comment 16

[Boris Zbarsky [:bzbarsky]]

The generic constructor macros are xpcom, not networking...

Comment 17

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(I tested this on latest-trunk mozilla-central nightly build on WinXP SP3)

Turning security-sensitive just-in-case, due to
!exploitable PROBABLY_EXPLOITABLE result.


0:019> !exploitable -v
HostMachine\HostUser
Executing Processor Architecture is x86
Debuggee is in User Mode
Debuggee is a live user mode debugging session on the local machine
Event Type: Exception
*** WARNING: Unable to verify checksum for C:\Documents and Settings\Administrator\Desktop\firefox\nspr4.dll
*** WARNING: Unable to verify checksum for C:\Documents and Settings\Administrator\Desktop\firefox\xul.dll
Exception Faulting Address: 0x10
First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005)
Exception Sub-Type: Write Access Violation

Exception Hash (Major/Minor): 0xb270241.0x1b4d665e

Stack Trace:
ntdll!RtlpWaitForCriticalSection+0x8c
ntdll!RtlEnterCriticalSection+0x46
nspr4!PR_Lock+0x17
xul!nsSocketTransportService::Dispatch+0x24
xul!nsAStreamCopier::PostContinuationEvent_Locked+0x1e
xul!nsAStreamCopier::OnOutputStreamReady+0x19
xul!nsSocketOutputStream::OnSocketReady+0x84
xul!nsSocketTransport::OnSocketDetached+0x62
xul!nsSocketTransportService::DetachSocket+0x24
xul!nsSocketTransportService::DoPollIteration+0x226
xul!nsSocketTransportService::OnProcessNextEvent+0x16
xul!nsThread::ProcessNextEvent+0x32e
xul!NS_ProcessPendingEvents_P+0x29
xul!nsSocketTransportService::Run+0x7c
xul!nsThread::ProcessNextEvent+0x213
xul!NS_ProcessNextEvent_P+0x1b
xul!nsThread::ThreadFunc+0x6c
nspr4!_PR_NativeRunThread+0xdb
nspr4!pr_root+0xd
MOZCRT19!_callthreadstartex+0x48
MOZCRT19!_threadstartex+0x66
kernel32!BaseThreadStart+0x37
Instruction Address: 0x355c57

Description: User Mode Write AV near NULL
Short Description: WriteAV
Exploitability Classification: PROBABLY_EXPLOITABLE
Recommended Bug Title: Probably Exploitable - User Mode Write AV near NULL starting at nspr4!PR_Lock+0x17 (Hash=0xb270241.0x1b4d665e)

User mode write access violations that are near NULL are probably exploitable.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Note that this bug requires the calling JS to have system privileges.  If that's the case, then you don't need to exploit this crash; you can just do whatever you want directly.

So I don't think this should be security-sensitive, or have an sg: annotation.

I also still think this bug should either be wontfix or a duplicate of the general "make it impossible to createInstance services" bug we have lying around somewhere.

Comment 19

[Boris Zbarsky [:bzbarsky]]

And this certainly doesn't need to block any releases, imo.

Comment 20

[Daniel Veditz [:dveditz]]

(In reply to comment #18)
> So I don't think this should be security-sensitive, or have an sg: annotation.

Whether this is exploitable or not, we need somehow to distinguish "crashes we've evaluated for security risk" from "crashes we have not". If you think it's not exploitable it should at least have "[sg:nse]" ("Not a Security Exploit") so we can track the fact that we've looked at this.

> [this should be] a duplicate of the general "make it impossible
> to createInstance services" bug we have lying around somewhere.

That sounds reasonable. I couldn't find that bug so I'll leave this for now.

Comment 21

[Mike Beltzner [:beltzner, not reading bugmail]]

As per comment 19, not blocking.

Comment 22

[Jesse Ruderman on Windows]

I think bug 336927 and bug 494946 cover the "make it impossible to createInstance services" issue, although bz might have had another bug report in mind.