On 10/29/21 4:58 AM, Alan Bateman wrote:
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
There are many security mechanisms in Derby. Application designers pick
and choose the mechanisms they think are useful. So, yes, many
applications load unsigned jars into the database. For applications
which require signed jars, this poses a vulnerability which didn't exist
before. At first blush, the jar appears to be signed.
