ZipFile.isSignatureRelated returns true for files in META-INF subdirectories

[Eirik Bjørsnøs]

Thanks for forwarding me to the right list, Alan

For context, I posted a follow-up on the core-libs-dev thread yesterday
showing that some other methods have the same problem:

https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/098656.html

And here's a draft PR for a fix, including a test which provokes the
various code paths:

https://github.com/openjdk/jdk/pull/11976

Cheers,
Eirik.


On Fri, Jan 13, 2023 at 9:32 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
> Forwarding to security-dev as that is where issues around signed JARs are
> usually discussed.
>
> -Alan.
>
>
> On 10/01/2023 17:00, Eirik Bjørsnøs wrote:
>
> Hi,
>
> ZipFile.isSignatureRelated currently returns true for paths such as the
> following:
>
>
> META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA
>
> While this path does start with "META-INF/" and ends with ".DSA", the file
> does not live in the META-INF/ directory _directly_, but rather several
> directories below.
>
> This causes such .DSA files to be incorrectly (?) included in the
> verification of META-INF/MANIFEST.MF in JarFile.initializeVerifier, which
> then fails with:
>
> Exception in thread "main" java.lang.SecurityException: Invalid signature
>> file digest for Manifest main attributes
>> at
>> java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:340)
>> at
>> java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:282)
>> at java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:327)
>> at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239)
>> at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:760)
>> at java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1058)
>> at
>> java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72)
>> at
>> java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:883)
>> at
>> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:848)
>> at
>> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>> at
>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>> at
>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>> at
>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>
>
> A few questions:
>
> 1: Where Is the exact location of signature related files specified?
>
> 2: Is the current behaviour indeed incorrect?
>
> 3: Should ZipFile.isSignatureRelated be updated such that it only matches
> signature related files which reside exactly in "META-INF/" ?
>
> The context for this is that I'm making a fat jar Maven plugin which
> embeds dependency jars by "unpacking" them into subdirectories of
> META-INF/libraries/.
>
> Cheers,
> Eirik.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230113/dc2a05ba/attachment.htm>