CVE for the new Java exploit?

[attritionorg]

Regarding: https://gist.github.com/frohoff/24af7913611f8406eaf3

Since you coordinated with Oracle and it is fixed in a fairly old version, can you ask what CVE ID that issue tracks to and update the advisory?

Thanks!

[frohoff]

Trying to figure out if there already is an existing CVE or not. The changelists with security changes for AnnotationInvocationHandler are associated with tickets S8001309 "Better handling of annotation interfaces" and S8035781 and "Improve equality for annotations". I will update if/when I find something, though it's possible @coekie might have some information in the meantime.

[coekie]

I don't know of any CVE assigned to these issues.

In case it helps to have the ticket numbers that Oracle used:
When I reported the initial issues with AnnotationInvocationHandler to Oracle (in 2011), they referred to that issue as S0079082 ("ISSUE IN SUN.REFLECT.ANNOTATION.ANNOTATIONINVOCATIONHANDLER").
The SerialDOS (also reported in 2011) was S0026831 ("JRE LOOPS DESERIALIZING OJECT GRAPH").
The more recent "More serialization hacks with AnnotationInvocationHandler" is S0641345.

[attritionorg]

Oracle's policy is that only the researcher who disclosed the vuln to them will be given the CVE, if requested. Else, it will stay vague in the CPU. Since @frohoff reported it (based on the gist link above) and they confirmed it was fixed, in theory they should give him the associated CVE, regardless of age. If there is none, then they silently patched it and never referenced it in a CPU.

That goes for @coekie as well; if you mail them asking the CVE for those internal tickets, they should match them up for you.

[frohoff]

My $0.02: I don't personally care about the CVE and am fine without one, but if people prefer to have one for tracking, it should probably be under @coekie's name since he did a bunch of work with them to have mitigations made.

[attritionorg]

In the Vulnerability Database world, it would help immensely. We know there is very likely a "remote issue in Java" that Oracle referenced in a previous CPU, but we can't give real details and link it to your writeup and exploit without. Since we're 99% sure it is disclosed via a CPU, we can't add a new entry as it would be a duplicate. I'd like to see the work associated with the right entry and the credit given where due.

[gsor]

I totally agree with @attritionorg - a CVE would be great. Also given that (probably? I am unable to check...) IBM could be affected, too and they usually closely follow Oracle's CPU with their fixes - referring to the same CVE IDs (http://www.ibm.com/developerworks/java/jdk/alerts/). Given that IBM offers long term support for Java 6 (and since recently even Java 5), there are many applications out there with a potentially vulnerable JRE embedded.
Last but not least openJDK and the related distros (RedHat etc.) who deliver it should have an interest, too.
So a CVE ID, along with accurate information, what versions are exploitable by that PoC would help a lot.
(Of course, still being aware that by moving to a non-vulnerable version of JRE is only the "tertiary mitigation measure", as @frohoff 's great writeup mentions.)

[frohoff]

Both @coekie and I have emails out to Oracle to ask about an existing CVE, so we'll see what they say. The June 2013 CPU that coincides with the 7u25 and 6u51 (post-EOL, non-public) releases credits @coekie for what I presume are the AnnotationInvocationHandler fixes, so it could be one of the vague "Unspecified vulnerability" CVEs, or may not have one at all.

[attritionorg]

Note that CVE-2015-7450 is for Commons-based Java deserialization issues in IBM Products, versus CVE-2015-4852 for Oracle (IBM mostly uses 7450 after I hounded them many times, but they still release the occasional advisory referencing 4852). Since it is one CVE per-vendor, there is a chance Oracle will lump your Java find into 4852 as well. Also note that IBM's Java apparently has enough code differences to manifest their own vulnerabilities not shared by Oracle Java. That, or they are really bad at making that clear and their advisories don't mention Oracle or cross-ref to known CVEs.

[gsor]

Agreed, the Commons Collections-based issue back in November 2015 was CVE per-vendor and Mitre made a clear statement about this (http://seclists.org/oss-sec/2015/q4/305). CVE-2015-4852 is for Oracle Weblogic and CVE-2015-7450 (for IBM Websphere). However they refer to individual applications (Weblogic/Websphere) and there were many CVEs issued for other applications affected by the Commons Collections-based exploit. I think, all of them have solved it differently (by either a. removing Commons Collections from the CLASSPATH completely, b. upgrading to the latest version Commons Collections, or - the advisable and sustainable way: c. remove unsafe deserialization to prevent from any type of this vulnerability class).
This one now is different as the PoC just requires the core Java classes (i.e. all Java-based applications, not only those that include Commons Collections are potentially affected - provided they run on a vulnerable implementation of Oracle or IBM Java or openJDK.
So I assume that this would create a lot of confusion if Oracle were to assign their Weblogic CVE to this core Java issue as well (and/or IBM were to assign their Websphere CVE to the IBM Java issue) - and I hope that this will *not * happen.

I don't think that IBM is too bad in referencing known CVEs in their Java, at least they always precisely refer to the corresponding Oracle Java CVEs and if they affect the IBM Java implementation, too (http://www.ibm.com/developerworks/java/jdk/alerts/). But I agree with you that they are really bad in providing more details beyond that. So if (e.g. in the recent case of CVE-2015-5041) this is about an IBM Java-only issue, you really have a hard time to find out what the issue is about at all.

[frohoff]

From the limited information @coekie and I have received back from Oracle Security, there is currently no CVE and they do not plan to assign a CVE for this issue. They are calling the aforementioned code changes that went out with the CPU "security-in-depth" fixes.

[attritionorg]

Awesome, thanks to both of you for following-up on that!

[frohoff]

Glad to help, though @coekie did most of the work chasing things down. I've updated the advisory gist's "CVE" entry with "N/A, Mitigated in June 2013 Critical Patch Update" and a link back to this issue for posterity.

[frohoff]

Closing since I don't know of anything else to be done here. Thanks, all.