Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spring-boot-starter-logging depends on vulnerable log4j version #28978

Closed
bmulder-innoseis opened this issue Dec 10, 2021 · 13 comments
Closed

spring-boot-starter-logging depends on vulnerable log4j version #28978

bmulder-innoseis opened this issue Dec 10, 2021 · 13 comments
Labels
status: invalid An issue that we don't feel is valid

Comments

@bmulder-innoseis
Copy link

bmulder-innoseis commented Dec 10, 2021

Spring-boot-starter-logging indirectly depends on log4j version 2.14 through the log4j-to-slf4j adapter dependency.

this version of log4j has been the subject of a zero-day vulnerability as explained here: https://www.cyberkendra.com/2021/12/worst-log4j-rce-zeroday-dropped-on.html

This means that all projects that use spring boot could be subject to that same zero-day whenever log4j code is actually executed directly or indirectly.

A related ticket has been opened here: #28958, but that one is talking about the optional log4j2 instead, which can optionally be updated through the log4j2.version variable. But this is about log4j without the 2, which by default is included in spring boot starters in maven.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Dec 10, 2021
@snicoll
Copy link
Member

snicoll commented Dec 10, 2021

As I've already explained in the related issue, log4j-to-slf4j is an adapter between the log4j API and slf4j. It brings indeed log4j-apibut does not bring log4j-core so our starter is not affected by this vulnerability.

@snicoll snicoll closed this as completed Dec 10, 2021
@snicoll snicoll added status: invalid An issue that we don't feel is valid and removed status: waiting-for-triage An issue we've not yet triaged labels Dec 10, 2021
@wilkinsona
Copy link
Member

wilkinsona commented Dec 10, 2021

But this is about log4j without the 2, which by default is included in spring boot starters in maven.

This is incorrect. The log4j-to-slf4j module is part of Log4j2 and overriding the log4j2.version property will affect the version of log4j-to-slf4j that spring-boot-starter-logging uses.

It's also worth reiterating that an application that depends on log4j-to-slf4j (which is used to route logging made using the Log4j2 API into a logging system other than Log4j2) is not vulnerable. To be vulnerable, you have to be using log4j-core and including user input in log messages.

@bmulder-innoseis
Copy link
Author

bmulder-innoseis commented Dec 10, 2021

Thank you for your explanation, it is clear now.

@jdelobel
Copy link

Hi,

I use spring boot 2.2.6.RELEASE and iam facing the log4shell issue (this version of spring boot use log4j2 2.12.1).
Actually lot of projects depends on our framework based on spring boot

We declare the dependancies management as follow

             <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <type>pom</type>
                <version>2.2.6.RELEASE</version>
                <scope>import</scope>
            </dependency>

and the log4j2 2.15.0 dependency is explicitly declared in another internal import.

But when check the dependancy tree

I found the 2.12.1 log4j2 version. I think spring boot override my framework's log4j's version.

How I can mange the dependancy properly (exclusion not work on import scope)?

We have already tried to add log4j2.version properties but it seems to not take effect for import scope declared in dependencyManagement as recommended on the website https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

Thanks
Julien

@philwebb
Copy link
Member

philwebb commented Dec 14, 2021

@jdelobel

The property override will only work if you are using our parent pom. For imports, you should use Maven's <dependencyManagement> tag.

Something like

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-bom</artifactId>
            <version>2.16.0</version>
           <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

I'll try to update the blog post when I get time.

@snicoll
Copy link
Member

snicoll commented Dec 14, 2021

The blog post you've referenced has a link to the instructions for Maven, this one specifically as you're not using the parent. Concretely this should be as follows:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-bom</artifactId>
            <version>2.16.0</version>
        </dependency>
        <dependency>
           <groupId>org.springframework.boot</groupId>
           <artifactId>spring-boot-dependencies</artifactId>
           <type>pom</type>
           <version>2.2.6.RELEASE</version>
           <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

The log4j dependency must be before our bom import (the link above explains that as well).

@jdelobel

This comment has been minimized.

@snicoll

This comment has been minimized.

@jdelobel

This comment has been minimized.

@snicoll

This comment has been minimized.

@jdelobel
Copy link

Hi,

Ok i will check it.

FYI, we use the 2.2.6.RELEASE version. Is it possible to create a 2.2.7.RELEASE with the 2.16.0 log4j version? I can do the PR but it my first time and im not sure that the pr will be validated to do the release?

Thanks

@snicoll
Copy link
Member

snicoll commented Dec 15, 2021

Is it possible to create a 2.2.7.RELEASE with the 2.16.0 log4j version?

Spring Boot 2.2.x is out of OSS support for over 2 years. Please upgrade to at least 2.5.x at your earliest convenience.

@jdelobel
Copy link

ok Thanks for your reply.

@snicoll snicoll unpinned this issue Jan 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: invalid An issue that we don't feel is valid
Projects
None yet
Development

No branches or pull requests

6 participants