previously prevented exploit now possible with JDK 18

Alan Bateman Alan.Bateman at oracle.com
Fri Oct 29 11:58:29 UTC 2021


On 28/10/2021 20:14, Rick Hillegas wrote:
> As a canary in the mineshaft, I built and tested Apache Derby with the 
> recent build 18-ea+20-1248 of Open JDK 18. I tripped across the 
> following issue when running Derby's regression tests. The problem is 
> explained in more detail at 
> https://issues.apache.org/jira/browse/DERBY-7126, where a simple repro 
> (DERBY_7126_A) can be found. The problem is almost surely the result 
> of work done on https://bugs.openjdk.java.net/browse/JDK-8269039 
> (Disable SHA-1 Signed JARs).
>
> Under previous versions of the JDK, the JVM would raise an error if 
> you tried to load a class from a jar file which had been signed with 
> SHA-1 but later hacked by inserting malware via "jar -uf". This was 
> the error:
>
>   SHA1 digest error for $corruptedJarFileName
>
> However, under JDK 18 the hacked class loads, no error is raised, and 
> the malware can now be executed. I was surprised that a previously 
> prevented exploit now works. I think it would be better if the JVM 
> still refused to load the hacked class even though SHA-1 has been 
> deprecated.

As I understand it, if the JAR file was signed with SHA-1 then it is now 
treated as unsigned. Are you saying that unsigned JARs are trusted in 
the environment?

-Alan



More information about the security-dev mailing list