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