mailing list archives
[SE-2012-01] Challenging Oracle (in a different way)
From: Security Explorations <contact () security-explorations com>
Date: Mon, 22 Oct 2012 12:01:37 +0200
On Oct 16, 2012, Oracle corporation released Java SE Critical Patch
Update , which incorporated fixes for 19 security issues that we
reported to the company earlier this year. This included a fix for
a serious Issue 32  found shortly after the out-of-band patch was
released by Oracle on Aug 30, 2012.
What's important to note is that this update did not incorporate the
fix for Issue 50  reported to the company on Sep 25, 2012 and that
affected all Java versions 5, 6 and 7 (versions 1.4 and 8 were also
verified to be vulnerable afterwards).
At the time of reporting Issue 50 to Oracle, we were not sure whether
the company would be able to address it by the Oct 2012 Java SE CPU
date. We at least hoped so. According to information received from
Oracle, the company planned to address issue 50 in Feb 2013. The fact
that Oracle decided to stick to its semi-quarter patch release cycle
was not understandable for us at all.
So, we have been exchanging emails with Oracle recently in order to
find out the reasons behind company's decision to wait with a patch
for a critical Java security issue for another four months. A summary
of that communication starting Oct 10, 2012 can be seen at our vendor
In general, Oracle's response was that their Critical Patch Updates
go through an extensive integration testing with other products such
as JRockit, Weblogic Server, and E-Business Suite and that any delay
in Oct Java SE CPU would result in a delay to deliver 139 fixes for
applications integrating Java SE. The company was in final stages of
extensive testing of October 2012 Java SE CPU when it received Issue
50 report. Upon evaluation of Issue 50 and the options to fix it,
company's assessment was that it was too late to include fixes in the
October Java SE CPU.
We might understand all of the above. But still, does it really take
more than four months (almost five if counting from Sep 25, 2012) to
fix a critical issue in Java ?
So, we decided to verify Oracle's claims on our own and conducted a
small Vulnerability Fix Experiment. We simply decided to see how hard
it is to fix Issue 50 and what it takes to accomplish it.
This experiment has lead us to the following conclusions:
- a fix for Issue 50 can be implemented within half an hour time
(start time 22:37 is the time of the OpenJDK 7 source code tarball
download, end time 23:03 is the time of the "application" of the fix
to JRE 7 installation directory).
- only 25 characters needed to be changed (removed / added) in a source
code in order to implement the fix,
- the fix does not seem to require any integration tests with other
Oracle application software (code logic is not changed at all,
minor changes are applied to the code, none of them influence
what could be described as an externally visible scope affecting
3rd party applications).
We provided Oracle corporation with the results of our analysis on
Oct 19, 2012.
We hope our quick experiment sufficiently challenges the company
and that it leads to the verification of Oracle's stance, especially
the one relying on a need for four additional months to implement
and release a security update for a critical security issue in Java
(Issue 50), which we believe (and are hopefully correct with respect
to the analysis conducted) can be addressed within less than 30 min.
"We bring security research to the new level"
 Oracle Java SE Critical Patch Update Advisory - October 2012
 [SE-2012-01] New security issue affecting Java SE 7 Update 7
 [SE-2012-01] Critical security issue affecting Java SE 5/6/7
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
- [SE-2012-01] Challenging Oracle (in a different way) Security Explorations (Oct 22)