Oracle set another record with its latest quarterly Critical Patch Update (CPU), which included 308 vulnerability fixes, 32 of which were Java-related. Released earlier this month, this CPU more than doubles the 136 fixes issued just over a year ago.
That last insight came my way from the folks at Waratek, the Dublin-based app security tools provided with a special focus on Java. I talked with the company’s lead security architect, Apostolos Giannakidis, about this CPU, and he argued that the high number of vulnerabilities in the Java Runtime Environment (JRE) covered by this release demonstrates that the Java SE platform continues to be a very popular attack vector.
“The attack vector of the Java platform is huge,” he told me. “More and more vulnerabilities are discovered that affect both the legacy and newer versions. Attackers are able to compromise applications and systems specifically by attacking the runtime itself — and, this trend keeps increasing at a fast rate.”
Of the 32 Java-related vulnerabilities covered in this CPU, 10 earned high-risk CVSS ratings. Oracle uses the Common Vulnerability Scoring System (CVSS) to provide an open and standardized rating of the security holes it finds in its products. Each vulnerability is issued a unique CVE number.
This CPU includes fixes for vulnerabilities in a range of Java components, including AWT, ImageIO, JavaFX, JAXP, ThreadPoolExecutor, AsynchronousChannelGroup, LambdaFormEditor, LDAP, Nashorn, JAR verifier, DSA, ECDSA, Elliptic Curve, X.509, PKCS#8 and the HotSpot VM. These vulnerabilities could allow attackers to escalate their privileges, corrupt the JVM’s memory, crash the JVM or execute arbitrary code and system commands.
Giannakidis pointed to two new vulnerabilities fixed in this CPU in the serialization component of the JVM that would allow the excessive allocation of memory. (Serialization is the process of converting an object into a stream of bytes for transport and storage.) He also pointed to fixes in this release to deserialization vulnerabilities in the RMI and in the Distributed Garbage Collector. (Deserialization reverses the process when the data is received.)
“This is despite the fact that the January CPU addressed deserialization vulnerabilities in the same components,” Giannakidis said. “This demonstrates that there are still critical deserialization attack vectors in the Java platform itself. I would have to say that it looks very much like Oracle is playing the Whac-A-Mole game with the deserialization vulnerabilities.”
The problem here is that the Java Runtime is one of the most complex runtimes, he added. “The amount of lines of code in the code base is considerable,” he said. “With such a big code base, it makes sense that you are going to have increased vulnerabilities. The important thing to remember is that these vulnerabilities were already there, lurking in the code base for a long time, based on my analysis. It’s a matter of spending time finding them. In fact, the vulnerabilities in the runtime are now the focus of the security community.”
Each quarterly CPU is a set of patches for multiple vulnerabilities put together since the previous update. They do not include the security advisories from previous updates; those are available on the Oracle Technology Network Web site. However, most CPUs are cumulative, Oracle has said, which means the application of this CPU should resolve new vulnerabilities and previously-reported security issues.
Oracle CPU updates are issued on a quarterly schedule announced at the beginning of the year. The purpose of that schedule is to provide users of Oracle products with a level of predictability that will foster regular maintenance activity, the company has said. The next CPU is scheduled for release on Oct. 17.
This article appeared in Waters Works by John Waters
