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

[Alan Bateman]

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.

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

[Eirik Bjørsnøs]

>
> 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
>

I found a couple more call sites of SignatureFileVerifier.isBlockOrSF which
incorrectly treat [SF,DSA,RSA,EC] files as signature related even when they
reside in subdirectories of META-INF/:

o JarVerifier.beginEntry incorrectly sets up verification
o JarSigner.sign0 incorrectly identifies a jar as already signed, even when
it is not

I have made a draft PR which updates these call sites to require files to
reside directly in META-INF/ before they are considered signature related:

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

The PR includes a new test which verifies that subdirectory signature files
are indeed ignored by the updated code

Feedback on this PR is welcome!

A few questions:
>
> 1: Where Is the exact location of signature related files specified?
>

I'm assuming the JAR File Specification is the normative source here [1]


> 2: Is the current behaviour indeed incorrect?
>

The spec says: "Note that if such files are located in META-INF
subdirectories, they are not considered signature-related"


> 3: Should ZipFile.isSignatureRelated be updated such that it only matches
> signature related files which reside exactly in "META-INF/" ?
>

I guess there is a risk that jar files may exist which are signed with
signature files in subdirectories. If such files exist, they are not
produced with jarsigner and they are not according to the spec.

Eirik.