Unofficial patches have been released for two unfixed Oracle Java Runtime Environment (RE) vulnerabilities discovered by Google Project Zero researcher Mateusz Jurczyk.
On February 18, Google Project Zero made public the details of four Java RE vulnerabilities caused by heap-based out-of-bounds read bugs. The security holes were discovered during fuzz testing aimed at the processing of TrueType and OpenType fonts. Project Zero tracks them internally as 1779, 1780, 1781 and 1782.
The flaws, described by Project Zero as “medium severity,” were reported to Oracle on February 12 and their details were disclosed less than a week later after the vendor said it would only address the issues in a future release of Java as a Security-in-Depth improvement rather than actual vulnerabilities due to the fact that the “scenario described does not provide a way for an attacker to exploit the user system directly.”
When it disclosed the vulnerabilities on February 18, Project Zero marked them as “WontFix.” However, Oracle changed its mind in mid-March and decided that it will patch them in a future release of Java RE.
ACROS Security’s 0patch third-party patching service, for which a PRO version was recently launched, decided not to wait around for Oracle and created its own fixes that Java users can obtain for free and easily deploy.
0patch has released micropatches for two of the four bugs, but it told SecurityWeek that it will soon release fixes for the other two as well.
The patches prevent exploitation of the flaws by terminating the execution of java.exe when out-of-bounds access is detected. “We felt trying to sanitize malicious input was too risky and could just move the vulnerability elsewhere,” 0patch explained.
The company says the patches only apply to Java 8 update 202, the Patch Set Updates (PSU) version in which Project Zero discovered the flaws. Oracle’s Critical Patch Updates (CPU) include only fixes for critical flaws, while PSU also include non-critical fixes. Java users who typically install only CPU are currently on update 201 and 0patch says it may port its micropatches to this version as well.
Oracle’s next CPU is scheduled for April 16. It remains to be seen if it will include patches for these flaws.
On their own, these vulnerabilities don’t pose a serious risk to Java RE users.
“Exploitability seems to be pretty low — anything outside of DOS is speculation at this time, but perhaps someone could use them for defeating ASLR. A remote attack is only possible if the attacker can supply their own font to the Java server, which will then render it,” Mitja Kolsek, CEO and co-founder of ACROS Security, told SecurityWeek.
However, Kolsek says his company has a very good reason for releasing patches for these vulnerabilities.
“The main point is to demonstrate that Java, which is a huge pain point in enterprises, can also be patched by someone other than Oracle,” he explained. “Another point is that for vulnerabilities that are publicly disclosed, the distance between ‘unlikely to be exploited’ and ‘exploited in the wild’ can turn out to be very short — if someone found another, more powerful 0day that would require breaking ASLR, they could use this ‘unlikely to be exploited’ vulnerability to make a full exploit chain.”
“Exploitation is a weird game and by closing such publicly known holes we can make an important impact (or none at all, and we may even never know),” Kolsek added.
0patch previously released micropatches for flaws affecting Windows, WinRAR, OpenOffice, Microsoft’s JET Database, and Adobe Reader.
