Vulnerability in quarkus-core dependency

[expertesantos]

Hi everyone,

I’m facing an issue with Quarkus. The company I work for is strict about vulnerabilities, and AWS Amazon Inspector has pointed out that the Quarkus project is using the library org.jboss.logging.jboss-logging-3.6.0.Final.jar, which relies on the log4j version 1.2.17, leading to several vulnerabilities being flagged: CVE-2019-17571, CVE-2022-23305, CVE-2023-26464, CVE-2022-23302, CVE-2022-23307, CVE-2021-4104, CVE-2020-9488.

I tried to exclude the jboss-logging dependency, but this library is used in quarkus-core, and I encountered the following error:

org/jboss/logging/BasicLogger: java.lang.NoClassDefFoundError
java.lang.NoClassDefFoundError: org/jboss/logging/BasicLogger
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
        at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.base/java.net.URLClassLoader.defineClass(Unknown Source)
        at java.base/java.net.URLClassLoader$1.run(Unknown Source)
        at java.base/java.net.URLClassLoader$1.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Unknown Source)
        at java.base/java.net.URLClassLoader.findClass(Unknown Source)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        at io.smallrye.config.SmallRyeConfig$ConfigSources.getSources(SmallRyeConfig.java:968)
        at io.smallrye.config.SmallRyeConfig$ConfigSources.<init>(SmallRyeConfig.java:804)
        at io.smallrye.config.SmallRyeConfig.<init>(SmallRyeConfig.java:86)
        at io.smallrye.config.SmallRyeConfigBuilder.build(SmallRyeConfigBuilder.java:736)
        at io.quarkus.runtime.generated.Config.<clinit>(Unknown Source)
        at io.quarkus.runner.ApplicationImpl.<clinit>(Unknown Source)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Unknown Source)
        at io.quarkus.runtime.Quarkus.manualInitialize(Quarkus.java:236)
        at io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler.<init>(QuarkusStreamHandler.java:21)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
        at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source)
        at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source)
Caused by: java.lang.ClassNotFoundException: org.jboss.logging.BasicLogger
        at java.base/java.net.URLClassLoader.findClass(Unknown Source)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        ... 25 more

I saw that there’s already a discussion on the jboss-logging project, but there hasn’t been any movement: jboss-logging/jboss-logging#111

Considering that I cannot deploy with AWS Amazon Inspector raising this issue, do you have any suggestions?

[phillip-kruger]

//cc @dmlloyd

[dmlloyd]

It does not in fact actually include log4j. It is only in the dependency list with a provided scope, meaning that jboss-logging may be used with systems which use log4j for logging. Quarkus is not such a system.

[dmlloyd]

Since we do not include log4j, this is not an issue (note that the dependency is provided scope). Unfortunately these vulnerability scanners don't always understand the nature of a dependency. But, jboss-logging cannot be said to depend on log4j in any logical sense.

[nicklasweasel]

Hi, did you file a ticket with AWS or find any other workarounds? I turned on Lambda scanning and now I also have multiple pages of "critical" findings...

[expertesantos]

Oh, maybe a simpler solution would be a / exclusion in the dependencyManagement of the build parent?

@dmlloyd do you mean on the Quarkus side?

@expertesantos is your report per dependency or it's a global report for your app and if our BOM exclude the dependencies entirely, that might work? Maybe you could experiment a bit with it and report back?

@gsmet It's a scan that analyzes the dependencies of my application, which is a Lambda (serverless).

I'm not sure if I understood, but I did the following test:

• I cloned the repository https://github.com/quarkusio/quarkus;
• I made the changes from the PR Exclude dependencies of jboss-logging #43861;
• I ran the command mvn clean install -DskipTests in the root directory of the project;
• In my project, I changed the Quarkus version to 999-SNAPSHOT;
• I deployed my project and ran the scan;
• The Log4j vulnerability is still appearing.
• A new vulnerability has been listed: CVE-2011-4605 - org.jboss.naming in the library lib/org.jboss.jboss-transaction-spi-8.0.0.Final.jar/META-INF/maven/org.jboss/jboss-transaction-spi/pom.xml.

[dmlloyd]

Ah. Unfortunately then the only conclusion I can arrive at is that your scanner is fatally broken. It's reporting artifacts as risks which are not actually in the project. There is no logical basis for such an error. This is similar to flagging an error because the string "log4j" appears somewhere in the program text - or because there are an even number of bytes in an artifact. It does not indicate anything of use.

It is generally not possible to accommodate illogical software. We can throw things at the wall all day but nothing we do will be "correct", and we would risk breaking other things in the meantime even if we did hit on the magical combination that allowed the scan to pass. I think an upstream bug fix on the scanner is the only way forward.

In the meantime, I would recommend filtering out any dependency which is not present in the final artifact.

[expertesantos]

Regarding changing the use of log4j to reload4j in the jboss-logging project, is that not an option?

[nicklasweasel]

The absurd thing is that if you deploy the lambda as native, the "problem" goes away. Hell, you could even have the vulnerable log4j compiled in there and the scanner wouldn't detect it.

However, I agree with @expertesantos that it's a real problem for some organizations and for people trying to get their system pass the AWS FTR, projects that Quarkus would probably want to have as references.

[dmlloyd]

Regarding changing the use of log4j to reload4j in the jboss-logging project, is that not an option?

Sure, we can definitely try it and see what happens. Overall though I think the responsibility for accuracy lies with the maintainers of the scanner.