-----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-----
