Date: Thu, 21 Oct 2010 16:13:35 -0400
From: Mike Duncan <Mike.Duncan@...a.gov>
To: Roberto Suggi Liverani <roberto.suggi@...urity-assessment.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: Security-Assessment.com Advisory: Oracle JRE -
 java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/20/2010 10:11 PM, Roberto Suggi Liverani wrote:
<snip />
>  
> In Java SE 6 update 10, both the Java Web Start and Java Plug-In
> technologies contain preliminary support for cross-domain policy
> files, which specify how unsigned code may access web services on the
> Internet. The crossdomain.xml policy file is hosted on a given server
> and allows either selected clients, or clients from anywhere, to
> connect to that server. Cross-domain policy files make accessing web
> services much easier, particularly from unsigned applets.

Great...something else to worry about which uses crossdomain.xml.  :/

I admit, I did not know about this functionality being added. I
apologize for not doing some homework ahead of time.

Personally, I think it is a step in the wrong direction by Java
developers. Research shows the only reason this functionality was added
was to keep Java in the same market space as other technologies which
already use crossdomain.xml functionality (e.g. Silverlight and Flash).

Back to the matter at hand...that same page also states...

"Access to a particular server is only granted if the crossdomain.xml
file is present and contains only an entry granting access from all
domains."

Wouldn't this mean that functionality was documented and functioning as
documented? I am not saying there is no issue here, but it seems like
you "discovered" something which was documented.

<snip />

>  
> Again, the Java Applet is *unsigned* and there is *no* crossdomain.xml
> policy
> which set rules of access control between www.targetsite.net and
> www.badsite.com

But, my point is that the current functionality is documented to ignore
the "set rules" you mention. In fact, there really are no rules for the
client to go by -- either the file is present and you can connect
(domain="*") or a signature is needed. The JVM does not read the domain
attribute to know whether or not to abide by SOP policies.

<snip />
>  
>  
> You need to rename MaliciousJavaApplet.java to MaliciousJavaApplet2.java
> and then
> compile it or change MaliciousJavaApplet2 to MaliciousJavaApplet in the
> source code.
> That was against script-kiddies...

Come on now. Renaming the file is not a script kiddie protection measure
when the domains to talk to are hard coded. I did not mean this to
be a cut-down or something against your programming skills, but a note
to others who may test out this vulnerability as well using your code
provided.

>  
> Then:
>  
> javac MaliciousJavaApplet2.java or javac MaliciousJavaApplet.java
> (depending which change you made)
>  
> No compilation issues for me.

Once renamed, as you stated above, I did not have any issues running the
code either.

>  
>  
> [...]
> We appreciate the responsible disclosure, but I am looking at the
> advisories for Oct 2010 from Oracle (see
> http://www.oracle.com/technetwork/topics/security/cpuoct2010-175626.html
> ) and
> I do not see this "fix" listed anywhere. I see Java VM stuff but only in
> the context of being fixed as part of another, parent component like
> Database Server.
>  
> Am I looking in the wrong place?
> [...].
>  
> Yes. Have a look here:
>  
> http://www.oracle.com/technetwork/topics/security/javacpuoct2010-176258.html
> 
>  
> FYI - bug has an internal Oracle/Sun ID 6980004 - and a CVE-2010-3573 as
> well.

You have to admit here, the documents online barely touch on the actual
issues with the code. For instance,
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3573 basically
just states that there exist issues "via unknown vectors". Some smaller
amounts of additional info can be gathered from here too:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3573.

Hell, I actually found a lot of misinformation about this CVE as well
while searching for it. Some places stated it was an issue in how the
JVM parses request headers which is clearly not your issue here. Perhaps
your issue was bundled with other -- who knows. I would seriously have
no idea what the CVE is supposed to address if you had not posted this
message.

I am hopeful that this discussion will change the crossdomain
functionality present in the JVM. I applaud you for disclosing this
issue, but I think this was a documented feature -- even if it was
.5-ass'ed put together by the Java devs.

<snip />

Thanks Roberto.

Mike Duncan
Dep. ISSO, Application Security Specialist
National Climatic Data Center, NOAA

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzAnu4ACgkQnvIkv6fg9hbg2wCfTZB880GyBfdUVH4VxY1Ohp95
hzwAnRFOciZ/4vL507DQCSSo2K9Z9RBv
=nniH
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists