[jira] [Commented] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18

["Richard N. Hillegas (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439382#comment-17439382 ] 

Richard N. Hillegas commented on DERBY-7126:
--------------------------------------------

The engineer responsible for the work on https://bugs.openjdk.java.net/browse/JDK-8269039 had this to say about the security regression we stumbled across. It appears that the Open JDK team is not going to fix this behavior:

{noformat}
Hello Rick,

It is behaving as expected. Let me explain in more detail.

First, loading a signed JAR off the classpath only verifies the
signature and digests of the JAR file. It does not validate the signer's
certificate chain or determine if the signer is trusted. The JarFile API
class description includes this warning [1]:

"Please note that the verification process does not include validating
the signer's certificate. A caller should inspect the return value of
JarEntry.getCodeSigners() to further determine if the signature can be
trusted."

Some frameworks such as Web Start have this additional checking
built-in. Or, if you run your code with a Security Manager, then
additional steps will be performed at run-time to check that the code is
signed and that the signer's public key is trusted before granting
permissions to that code.

If you don't perform these additional steps, then the JAR can be
modified without detection. For example, the signature related files
could be removed from the JAR (thus making it an unsigned JAR), or the
JAR could be modified and then re-signed with a different key. In either
of these cases, the JVM would load the JAR without any exception.

It is also possible that a JAR signed with a weak or broken algorithm (such as MD5 or SHA-1) could be modified without detection.

This is why the JDK implementation supports several security
properties which are used to disable cryptographic algorithms and
protocols that are weak or broken. This provides out-of-the-box security
and is important to safeguard against crypto algorithms that inevitably
become weaker over time. One of these properties is
"jdk.jar.disabledAlgorithms". The specification of this property defines
the behavior if a signed JAR file is signed with an algorithm that is
disabled [2]:

"JARs signed with any of the disabled algorithms or key sizes will be
treated as unsigned."

The JDK determined after step 1 of the JAR verification process [3] that
the JAR was signed with SHA-1, and therefore stopped further processing.

You may ask why we don't throw an Exception in this case. Although this
was considered, the compatibility risk was too high. These
restrictions are nearly always backported to earlier JDK update
releases. Throwing an Exception would be too high of a risk for
applications that happen to load signed JARs off the classpath but don't
otherwise behave any differently. Our primary focus is to protect
applications that verify that the code is signed by someone they trust.

Consider updating and re-signing your signed jar with a stronger, non-broken algorithm such as SHA-2. SHA-2 is the default digest algorithm used by jarsigner when the -digestalg option is not specified.

I hope this information is useful. I do think this is an area where our
javadocs and guides could be improved to provide more information about
how signed JARs are verified including more details on the behavior of
the JDK implementation with respect to disabled algorithms. We will be
working to try to improve the docs for JDK 18.

--Sean

[1]
https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/util/jar/JarFile.html
[2]
https://github.com/openjdk/jdk/blob/master/src/java.base/share/conf/security/java.security#L667
[3]
https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html#signed-jar-file
{noformat}

I'm not sure how to address the fallout from this change. Here are some ideas:

1) Add a release note about this issue to the next Derby release (maybe update the download pages for the currently mirrored releases 10.15.2.0 and 10.14.2.0).

2) Remove support for signed jars files from our security documentation. I don't think that our support for signed jar files does enough to be worth advertising. The most significant part (verifying the identity of the signer) has always been left to the application.


> Make it possible to build and test Derby cleanly with OpenJDK 18
> ----------------------------------------------------------------
>
>                 Key: DERBY-7126
>                 URL: https://issues.apache.org/jira/browse/DERBY-7126
>             Project: Derby
>          Issue Type: Task
>          Components: Build tools
>    Affects Versions: 10.16.0.0
>            Reporter: Richard N. Hillegas
>            Assignee: Richard N. Hillegas
>            Priority: Major
>         Attachments: DERBY_7126_A.java, dcl_emc2sm.jar, derby-7126-01-aa-regenerateSignedJars.diff
>
>
> Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should adjust Derby as necessary so that it builds cleanly (including javadoc) and tests cleanly with this version of the platform.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)