402995 - (CVE-2008-1195) jar: protocol content can use LiveConnect to connect to arbitrary ports on localhost

Status: RESOLVED FIXED

(Core :: Security, defect, P2)

Description

[Gregory Fleischer]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Content that is retrieved using the 'jar:' protocol can use LiveConnect to connect to arbitrary ports on the localhost.  There is some miscalculation as to the origin of the content, and LiveConnect/Java plugin appear to believe it originated from the localhost.  Consequently, arbitrary socket connections are allowed to the localhost.

This vulnerability could place services that are normally only available from the localhost at increased risk of exploitation.

Write-up and demonstration available from: http://pseudo-flaw.net/jar-test/ 


Reproducible: Always




Firefox 2.0.0.9 on Linux and Windows are affected.  Latest nightly Minefield appears not to be vulnerable.

Comment 1

[Benjamin Smedberg]

Have you reported this to Sun as well? I think we'd try to fix it if we knew how, but it really sounds like a Java bug.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> Latest nightly Minefield appears not to be vulnerable.

That's very curious.

Can someone narrow down when the behavior changed?  I don't have a working Java here, unfortunately...

Comment 3

[Martijn Wargers (dead)]

It stopped working for between 2006-05-10 and 2006-05-12:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-10+11&maxdate=2006-05-12+08&cvsroot=%2Fcvsroot

Note that with current trunk document.domain == null with jar:http://pseudo-flaw.net/jar-test/content.zip!/whatdomain.html which seems a bug in Firefox to me.

Comment 4

[Gregory Fleischer]

(In reply to comment #1)
> Have you reported this to Sun as well? I think we'd try to fix it if we knew
> how, but it really sounds like a Java bug.
> 

No, this has not been reported to Sun.  I'm not convinced that this a problem in the Java plugin.  If the problem was reproducible in the latest Minefield, the issue would most likely be originating in the JRE.  But, there is differing behavior between 2.0.0.9 and Minefield with the same exact JRE plugin.

I've retested with the latest nightly builds and Java plugin versions.

VULNERABLE
  - Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.10pre)
    Gecko/20071108 BonEcho/2.0.0.10pre
    - Java(TM) Plug-in 1.6.0_02-b05
    - Java(TM) Plug-in 1.6.0_03-b05
  - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10pre)
    Gecko/20071108 BonEcho/2.0.0.10pre
    - Java(TM) Platform SE 6 U3

NOT VULNERABLE
  - Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre)
    Gecko/2007110804 Minefield/3.0b2pre
    - Java(TM) Plug-in 1.6.0_02-b05
    - Java(TM) Plug-in 1.6.0_03-b05
  - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre)
    Gecko/2007110805 Minefield/3.0b2pre
    - Java(TM) Platform SE 6 U3

Comment 5

[Boris Zbarsky [:bzbarsky]]

> It stopped working for between 2006-05-10 and 2006-05-12:

That's really odd.  I don't see any obvious changes to security policy in there on our end...

Any chance of narrowing down the range somehow?

> Note that with current trunk document.domain == null 

The same is true on branch.  The question of what GetHost should be on jar: URIs has come up before; I wonder whether this code should dig into the URI manually... probably worth filing a bug on this, at least.

Comment 6

[Boris Zbarsky [:bzbarsky]]

For what it's worth, on Linux I get a security exception thrown on both trunk and branch:

[*] Java is enabled
[*] LiveConnect present
[*] found Java plugin: Java(TM) Plug-in 1.6.0_01-b06 (libjavaplugin_oji.so)
[*] document.domain is null
[*] attempting socket connection to 127.0.0.1:80
[*] got sockaddr local address: 127.0.0.1, localhost.localdomain
[!] Error while constructing instance of java.net.Socket
[!] TypeError: socket has no properties

The Java console says:

java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation.ConstructObject(Unknown Source)
	at sun.plugin.navig.motif.AThread.handleRequest(Native Method)
	at sun.plugin.navig.motif.AThread.JNIHandleLoop(Unknown Source)
	at sun.plugin.navig.motif.AThread.run(Unknown Source)
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at sun.plugin.liveconnect.PrivilegedConstructObjectAction.run(Unknown Source)
	... 7 more
Caused by: java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:80 connect,resolve)
	at java.security.AccessControlContext.checkPermission(Unknown Source)
	at java.security.AccessController.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkConnect(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at java.net.Socket.<init>(Unknown Source)
	at java.net.Socket.<init>(Unknown Source)
	... 12 more

Comment 7

[Boris Zbarsky [:bzbarsky]]

Ria, Steve, can you help out with the "when did this stop working on trunk?" range?

Comment 8

[Jeff Walden [:Waldo]]

(In reply to comment #5)
> That's really odd.  I don't see any obvious changes to security policy in there
> on our end...

Bug 336303 is in that range -- you sure it isn't that?  Alternately, this looks like it was right after the thread manager landing, so maybe a nightly got skipped or something and the range should actually encompass that landing.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Bug 336303 is in that range

So it is.  I suppose that's possible...  Before that change, the origin was that jar: URI.  After it, it's the URI nested inside the jar: URI.  I do see OJI code getting the origin, but it just passes it off to the Java plugin, as far as I can tell.

And given that I'm not seeing the problem on branch with the plugin version here, and that there is no issue on Mac, I would agree that this is a plugin bug, I think...

We could change GetOrigin on branch, perhaps, but if the plugin is just buggy with URI stuff like that, there are plenty of other ways it could be exploited by using non-HTTP URIs....

Comment 10

[Gregory Fleischer]

(In reply to comment #9)
> > Bug 336303 is in that range
> 
> So it is.  I suppose that's possible...  Before that change, the origin was
> that jar: URI.  After it, it's the URI nested inside the jar: URI.  I do see
> OJI code getting the origin, but it just passes it off to the Java plugin, as
> far as I can tell.

That is most likely where the issue is.  If the origin is being reported as the jar: URI, then that is the reason connections can be established.  Since a jar: URI has no host component and an empty host is equated with localhost, the JVM believes the content is coming from the localhost and can connect back to it.  This is similar to how a URI of "file:///foo/bar.html" has an empty host component so connections are allowed to the localhost.

> 
> And given that I'm not seeing the problem on branch with the plugin version
> here, and that there is no issue on Mac, I would agree that this is a plugin
> bug, I think...
> 

I tested on a fresh Ubuntu 7.10 (x86_64) install, latest BonEcho/2.0.0.10pre and the JRE versions 1.6.0_01, 1.6.0_02, and 1.6.0_03.  The problem was reproducible in all cases.

Apple ships its own version of Java (http://www.apple.com/support/downloads/javaformacosx104release5.html).  This was last updated in February and supposedly contains multiple severe vulnerabilities.  

Firefox for the Mac uses the MRJ plugin and is not vulnerable because it is correctly calculating the origin.  On my Mac, this is contents of the Java console from the jar: URI test page:

MRJ Plugin for Mac OS X v1.0.1
[starting up Java Applet Security @ Fri Nov 09 15:53:52 CST 2007]
<<< ProxyClassLoader: defined LiveConnectProxy class. >>>
<<< Here're the permissions you've got: >>>
<<< java.security.Permissions@b60280 (
 (java.net.SocketPermission pseudo-flaw.net connect,accept,resolve)
)
 >>>
java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:80 connect,resolve)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
 ...


> We could change GetOrigin on branch, perhaps, but if the plugin is just buggy
> with URI stuff like that, there are plenty of other ways it could be exploited
> by using non-HTTP URIs....
> 

I believe GetOrigin needs to correctly report where the content is derived from.

I tested both gopher: and ftp: protocol handling.  When wrapped with a jar: URI, the vulnerability is present.  When accessed normally, it is not.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Since a jar: URI has no host component and an empty host is equated with 
> localhost

That's a serious security bug in the JVM, if that's what it does.  The two are NOT the same.  There are lots of URIs that have no host component anywhere in sight.  data: comes to mind.

> The problem was reproducible in all cases.

Odd.  I'm definitely getting that security exception I cited above with the JRE version I have on FC3...

> I believe GetOrigin needs to correctly report where the content is derived
> from.

It does that, in general.  That would be the URI.  We happen to have some special knowledge of jar: URIs that allows us to report the site the jar: is loaded from instead, but we're possibly considering changing that in any case.  At which point as far as the entire security system in Gecko is concerned the origin will simply be the jar: URI.

More importantly, there are plenty of other URI types out there that could be loading Java.  data:, as I said.  Heck, any extension can implement a protocol handler for any scheme it wants.  URIs need not have hosts.  Treating any URI without a host as coming from localhost, even if the URI scheme in general can't have a host, is a security bug, pure and simple.

So the key is that we could change the behavior of jar: and the vulnerability would remain: you'd just need to load your stuff via any of a number of methods that don't involve hosts and aren't jar:.  The only place that can be fixed is by fixing the silly localhost assumption in the plug-in.

Comment 12

[Gregory Fleischer]

(In reply to comment #11)
> 
> > The problem was reproducible in all cases.
> 
> Odd.  I'm definitely getting that security exception I cited above with the JRE
> version I have on FC3...
> 

I performed a default install of Fedora Core 3 under VMware and added the httpd package.  I did a "yum update" to the latest versions.  I installed the most recent BonEcho/2.0.0.10pre and Java Plug-in 1.6.0_01.  The issue was present.

I will continue investigating.

Comment 13

[Daniel Veditz [:dveditz]]

Attachment: zipped testcase

Preserving testcase for future reference

Comment 14

[Daniel Veditz [:dveditz]]

In OJI we could whitelist schemes--http(s), file, maybe ftp and gopher if we feel generous--and return an error for anything else. Or ensure the URI has a host or schemeIs file.
http://lxr.mozilla.org/mozilla/source/modules/oji/src/nsCSecurityContext.cpp#108 

Do we still use the MRJCarbon plugin on any branch? There's a minor problem where we delete[] a string that came from nsMemory::Alloc()
http://lxr.mozilla.org/mozilla/source/plugin/oji/MRJCarbon/plugin/Source/CSecureEnv.cpp#259

Comment 15

[Daniel Veditz [:dveditz]]

We probably want a fix on the trunk, too. These JAR testcases might be fixed but as bz points out in comment 11 a similar attack could probably be constructed using other hostless schemes.

Comment 16

[Damon Sicore (:damons)]

+'ing.  Setting to P2.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #14)

> Do we still use the MRJCarbon plugin on any branch?

The Java Embedding Plugin does (of course) use a forked descendant of
the MRJCarbon plugin (the JEP is bundled with Mozilla.org OS X distros
that can use Java http://javaplugin.sourceforge.net/).

> There's a minor problem where we delete[] a string that came from
> nsMemory::Alloc()

This problem is still present in the JEP's forked descendant of the
MRJCarbon plugin (what I call the "MRJ Plugin JEP").  But I've never
had any problems with it.

I _did_ (long ago) fix a much more serious bug in this code, which
caused frequent crashes:

"codebase" is uninitialized, and GetOrigin() can return NS_OK without
doing anything to "codebase" (thereby leaving it unitialized).  This
caused crashes at NewStringUTF.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

> GetOrigin() can return NS_OK without doing anything to "codebase"
> (thereby leaving it unitialized)

I just looked at nsPrincipal.cpp and found that this is no longer true
(on either the trunk or the 1.8 branch).

>> There's a minor problem where we delete[] a string that came from
>> nsMemory::Alloc()
>>
>> This problem is still present in the JEP's forked descendant of the
>> MRJCarbon plugin (what I call the "MRJ Plugin JEP").  But I've
>> never had any problems with it.

Do you know why I haven't had trouble using delete[] on something
allocated using nsMemory::Alloc()?  I haven't yet managed to figure
out nsMemory::Alloc() (or the underlying NS_Alloc()).  But I suspect
it's probably alright (though not quite kosher) to use delete[] on a
simple object (like a char*) that's been malloced.

Comment 19

[Benjamin Smedberg]

It is not acceptable to free[] a buffer that has been NS_Alloc'ed. Use NS_Free instead. It might work if you were linking the same CRT and it was never hooked, but that's not always a safe assumption.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

> It is not acceptable to free[] a buffer that has been
> NS_Alloc'ed. Use NS_Free instead.

I'll do this in my next release of the JEP.

But, given that the "bad" code is exercised very often, and that (as
far as I know) nobody has ever had any trouble with it, I don't think
this is urgent.

Comment 21

[Daniel Veditz [:dveditz]]

(In reply to comment #20)
> as far as I know) nobody has ever had any trouble with it, I don't think
> this is urgent.

I raised it mainly because of the recent noises about hooking in different allocators in attempts measure and deal with memory fragmentation; it might well _become_ an issue even if we've gotten away with it so far.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

OK, thanks.

If possible, please give me a warning when this seems about to happen.
Or point me to bug(s) where this possibility is being tracked.

I don't currently plan to release a new JEP for several months
... mainly because I'd be hard-pressed to find the time to deal with
the various issues (so far all of minor importance) that have come up
since the last JEP release.

Comment 23

[Mike Schroepfer]

Bz/DVeditz - do we have a conclusion as to whether this is a JRE, Plug-in, or Firefox issue?  

Comment 24

[Window Snyder]

This bug is currently classified as moderate, but I think the severity is higher. This allows an attacker to connect to any open port on the loopback device.  Lots of applications, like google desktop, use this without any authentication.  With google desktop (for example) an attacker can now steal any indexed file (which is usually every file that matters to the user.)

The loopback interface is only available locally.  The services listening are only available to the local machine as a mechanism for interprocess communication.  They are not protected by the host firewall since the interface is only accessible locally.  Most of them don't even use authentication.  It looks like this issue opens a vector that exposes services that listen on the loopback address to content from the web.

Comment 25

[Boris Zbarsky [:bzbarsky]]

It's a JRE bug (e.g. the JRE also allows file:// pages to connect to localhost, and we can't really fix that without also blocking access to other file:// URIs, which might in fact break things).

But we should do what dveditz suggests in comment 14.  I'd offer to, but I can't really test very well: about 70% of the time I load an applet, the browser completely hangs.  Might be better if someone who can actually test the patch writes it...

Comment 26

[Mike Schroepfer]

FYI Sun was contacted and has responded that they are helping look into it...

Comment 27

[Kenneth Russell]

Confirming that we are looking into this issue from our side.

It appears that applets, even unsigned applets, are uniformly granted permission to connect back to the localhost, and have been for many releases of Java. Personally I don't understand the reasons for granting this particular permission, but I imagine there would be compatibility problems with simply removing this permission as a fix for this issue. I'm not sure what other options are available on the JRE side for closing this hole. The appropriate people from Sun have been engaged, in particular those who were involved in the previous issue with the verbatim: protocol handler.

Comment 28

[Daniel Veditz [:dveditz]]

re: comment 11 -- data: URIs are OK because they do get an origin from the principal. At least data: URIs created by web content, ones that get a nsNullPrincipal would have this same problem.

Bailing out of GetOrigin() with an error on hostless schemes won't help -- if the JRE gets an error from here it apparently goes ahead and uses a null principal. That means another avenue for attack would be to try to launch from an origin longer than the buffer. Easy to do for schemes without a host, but pointless because you've already won. Schemes with a host have an origin of just the scheme+host+port which shouldn't exceed the 512-byte buffer--at least not according to the spec and not supported by us in FF2.0 and trunk as far as some quick testing shows (I got up to 263 counting the https scheme, plus I guess a few more for the port), but I'm not 100% confident without digging into necko code.

On the branch for jar: we could manually de-nest the URI, or even back-port nested-URI support and make GetOrigin() do the right thing. That still leaves other hostless schemes. Do we even want file: uris to be able to hit the loopback? Blocking that might break legit apps, but not blocking it means any saved web-page can poke at your machine and exfiltrate data. (see also bug 402998)

We could also make up a fake host for hostless schemes and return that: http://nohost.invalid -- of course maybe the JRE knows about rfc2606 and will map that back to localhost

Comment 29

[Kenneth Russell]

The root cause is a bug in the Java Plug-In and not in the web browser. The Java Plug-In models LiveConnect calls from untrusted JavaScript code as coming from untrusted Java code whose origin is the same as that of the document. Specifically, if the JavaScript code was downloaded over the network rather than fetched from a local file, then it is granted a SocketPermission to connect back to the originating host. (Comment 27, which I made above, is only correct in the case of applets fetched from files.)

The bug is an error in the Java Plug-In's code which parses the origin, which is passed in from the browser-side LiveConnect code. On Firefox 2, the origin passed in is the entire jar: URL. The Java Plug-In incorrectly determines that this URL has a null host and grants a SocketPermission to connect to a null host, which has the unexpected result that the LiveConnect calls from this web page may connect to localhost.

The fix, determined by [e-mail] and the rest of the security and networking teams, is to detect the situation where the host is null and make a best-effort attempt to handle the nested URL. In the case of failure, no SocketPermission is granted at all.

This fix will become available in a forthcoming release of the Java Plug-In. Thanks for the test case.

The reason the Firefox 2 browser is vulnerable and the Firefox 3 browser is not is that in Firefox 3 the origin passed in from the browser to LiveConnect calls is different and arguably more correct. In Firefox 2 it is the entire document base (e.g. jar:http://host.com/foo.zip!/bar.html) but in Firefox 3 it is http://host.com/ , so in Firefox 3 the bug in the Java Plug-In is not triggered.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Kenneth, I assume that means that for jar: the Java Plug-In will try to extract the nested URI (which might be multiply-nested if there are multiple jar: prefixes) and for other host-less schemes the SocketPermission won't be granted?

If so, that sounds fabulous.  Thanks for the quick response!

We should still do comment 14 for users who don't upgrade their Java install, I think.

Comment 31

[Kenneth Russell]

Boris: yes. Actually in our current fix we only attempt to dive one level into the nested URI (to stave off potential denial of service or other problems with pathological URIs), but otherwise what you've described is correct.

FYI, if it's straightforward to modify FF 2's OJI implementation to mimic FF 3's behavior regarding the origin of the LiveConnect call, that would be another possible workaround rather than simply blocking LiveConnect calls from all but a certain set of URL schemes.

Comment 32

[Boris Zbarsky [:bzbarsky]]

It's reasonably straightforward, but would only help with jar:.  Other schemes would still have issues...

What we should probably do is block all schemes for which GetHost() on the URI actually fails.

Comment 33

[Samuel Sidler (old account; do not CC)]

Moving this out to the next release.

Comment 34

[Stuart Parmenter]

"this doesn't look bad on trunk but if it really is free to renominate if there are real issues on trunk" -jonas

Comment 35

[Daniel Veditz [:dveditz]]

Sun's JRE 1.6_05 update fixes this testcase.

Comment 36

[Gregory Fleischer]

(In reply to comment #35)
> Sun's JRE 1.6_05 update fixes this testcase.
> 

Yes, the changes in JRE 1.6_05 appear to resolve the issue.

Currently, the Sun Alert for this issue http://sunsolve.sun.com/search/document.do?assetkey=1-66-233326-1 is reporting:

"""
This issue can occur in the following releases running Firefox 2.0.0.9 and earlier:

    * JDK and JRE 6 Update 4 and earlier
    * JDK and JRE 5.0 Update 14 and earlier
    * SDK and JRE 1.4.2_16 and earlier

Note: This issue does not occur on Firefox 2.0.0.10 or later and does not occur on all versions of Internet Explorer.
"""

This is clearly incorrect as the issue is still reproducible in Firefox 2.0.0.12 with JRE 1.6_04.

I sent an email to [e-mail] about this discrepancy after it was first posted, but haven't heard anything back.

Comment 37

[Kenneth Russell]

I am the engineer who was asked to confirm and reply to your email to [e-mail]. I apologize, but I do not have the time to re-verify this issue at this point. When I tested the original fix, the bug occurred with Firefox 2.0.0.9 but not with 2.0.0.10 due to an apparent tightening of security on the browser side. I don't know whether this was relaxed in a later Firefox build but the Sun security alert was correct as of the release of 2.0.0.10.

Comment 38

[Gregory Fleischer]

(In reply to comment #37)
> When I tested the original fix, the bug occurred with
> Firefox 2.0.0.9 but not with 2.0.0.10 due to an apparent tightening of security
> on the browser side. 

That's odd.  The change between 2.0.0.9 and 2.0.0.10 involved restricting jar: content to a files with a Content-Type header of "application/java-archive" or "application/x-jar" (http://www.mozilla.org/security/announce/2007/mfsa2007-37.html).  Possibly your tests didn't account for this and the content was being blocked because it didn't have the correct MIME type.

I re-tested 2.0.0.10 and 2.0.0.11 with JRE 1.6 update 4 on Linux:
==============================
[*] userAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10
[*] Firefox detected
[*] Java is enabled
[*] LiveConnect present
[*] found Java plugin: Java(TM) Plug-in 1.6.0_04-b12 (libjavaplugin_oji.so)
[*] document.domain is null
[*] attempting socket connection to 127.0.0.1:80
[*] got sockaddr local address: 127.0.0.1, localhost
[*] connected to port 80
[*] socket closed
==============================
[*] userAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
[*] Firefox detected
[*] Java is enabled
[*] LiveConnect present
[*] found Java plugin: Java(TM) Plug-in 1.6.0_04-b12 (libjavaplugin_oji.so)
[*] document.domain is null
[*] attempting socket connection to 127.0.0.1:80
[*] got sockaddr local address: 127.0.0.1, localhost
[*] connected to port 80
[*] socket closed
==============================

After applying JRE 1.6 update 5:
==============================
[*] userAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10
[*] Firefox detected
[*] Java is enabled
[*] LiveConnect present
[*] found Java plugin: Java(TM) Plug-in 1.6.0_05-b13 (libjavaplugin_oji.so)
[*] document.domain is null
[*] attempting socket connection to 127.0.0.1:80
[*] got sockaddr local address: 127.0.0.1, localhost
[!] Error while constructing instance of java.net.Socket
[!] TypeError: socket has no properties
==============================
[*] userAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
[*] Firefox detected
[*] Java is enabled
[*] LiveConnect present
[*] found Java plugin: Java(TM) Plug-in 1.6.0_05-b13 (libjavaplugin_oji.so)
[*] document.domain is null
[*] attempting socket connection to 127.0.0.1:80
[*] got sockaddr local address: 127.0.0.1, localhost
[!] Error while constructing instance of java.net.Socket
[!] TypeError: socket has no properties
==============================

Comment 39

[Daniel Veditz [:dveditz]]

porting the patch from bug 336303 to the 1.8 branch fixes this vulnerability for users who still have an older JRE (tested with 1.6.0_03).

Comment 40

[Daniel Veditz [:dveditz]]

Checked in the fix for bug 336303 to the 1.8 branch which fixes this for people who haven't yet upgraded to the latest versions of the JRE.

Comment 41

[Al Billings [:abillings - ex-MoCo]]

I verified the bug using Firefox 2.0.0.12 on Ubuntu 7.10 with JRE 1.6.0_03-b05. I then validated the fix using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/2008031115 Firefox/2.0.0.13, which is the RC1 for 2.0.0.13. The bug no longer reproduces in either of the jar: versions. 

Marking as verified for 1.8.1.13.