[SECURITY] RCE 0-day in log4j - Conclusion: Lombok itself not affected

[bauerpl]

Describe the bug
In log4j library was discovered a 0-day exploit that results in Remote Code Execution (RCE) by logging a certain string. The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1.

Additional context
https://www.randori.com/blog/cve-2021-44228/

Expected behavior
Immediate update of log4j library to the latest version (right now it is 2.15.0 according to the changelog)

Jump to latest assesment

[Rawi01]

Can you please explain how this affects lombok? As far as I know log4j is only required to run the tests without compilation errors.

[adambarney]

Lombok provides an annotation, @log4j, which generates a logger field using the apache Log4J library.

[rspilker]

@adambarney although Lombok generates code to create an instance of a logger, we do not ship, distribute or require any specific version, and the user needs to bring their own.

As @Rawi01 said, there is a version to be found in our code base, but that's only used inside testing code to be able to compile the generated code without errors.

So I would say that Lombok is still safe to use, but I don't see a reason NOT to update the dependency to a version that is currently considered safe.

[janrieke]

Lombok itself does not ship, require or depend on log4j. It just generates the code that references log4j. If log4j is not on the classpath, the compiler will complain.

[SunriseChair]

@adambarney although Lombok generates code to create an instance of a logger, we do not ship, distribute or require any specific version, and the user needs to bring their own.

As @Rawi01 said, there is a version to be found in our code base, but that's only used inside testing code to be able to compile the generated code without errors.

So I would say that Lombok is still safe to use, but I don't see a reason NOT to update the dependency to a version that is currently considered safe.

Wouldn‘t that dependency then be included if u declared lombok as a dependency in ur mvn/gradle? Making it probably the only one on the classpath which would in turn be picked up by the code generated by lombok?
Please correct me if I‘m wrong…

[RuanNunes]

doing a quick search in the repository found this property that presents vulnerability

lombok/src/support/log4j.properties

Line 6 in d3b763f

log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n

referency https://issues.apache.org/jira/browse/LOG4J2-2109

[rspilker]

@SunriseChair Lombok does not declare a dependency on log4j, or any other library.

If you would use the @Log4j annotation in your code without having a dependency on log4j directly or transitively, your compile would just generate an error message.

[rspilker]

@RuanNunes in the same directory is a text file explaining we do not ship that file as part of our release.

[vae520283995]

@rspilker Hello, I used the annotation @slf4j in lombok. Does this vulnerability have anything to do with me?

[bauerpl]

@adambarney although Lombok generates code to create an instance of a logger, we do not ship, distribute or require any specific version, and the user needs to bring their own.

As @Rawi01 said, there is a version to be found in our code base, but that's only used inside testing code to be able to compile the generated code without errors.

@rspilker After diving into the code I can confirm that you're absolutely right about this ⬆️ .

So I would say that Lombok is still safe to use, but I don't see a reason NOT to update the dependency to a version that is currently considered safe.

Absolutely! 👍

[rspilker]

@vae520283995, I cannot help you here. I have no knowledge about this vulnerability, and I wouldn't even understand why you would assume it would also affect @Slf4j.

I can tell you that Lombok does not ship, require or declare a dependency on any of those libraries.

We generate 'invisible source code'.

Please contact the maintainers of @Slf4j if you have any reason to suspect a similar problem might also occur in their product.

[vae520283995]

@vae520283995, I cannot help you here. I have no knowledge about this vulnerability, and I wouldn't even understand why you would assume it would also affect @Slf4j.

I can tell you that Lombok does not ship, require or declare a dependency on any of those libraries.

We generate 'invisible source code'.

Please contact the maintainers of @Slf4j if you have any reason to suspect a similar problem might also occur in their product.

Thank you, I checked, I am using springboot default logback

[rspilker]

Latest assesment

1. This vulnerability is only present in Log4j core binaries below version 2.16.0, and not in any other logging frameworks.
2. Lombok does not distribute any Log4j binaries, nor does it declare (transitive) dependencies on anything.
3. If you use any of the extern lombok features, like @lombok.extern.log4j.Log4j, lombok will generate code that will use those libraries, but you are responsible to have direct or transitive dependency on those libraries, otherwise the lombok generated code will not compile.
4. Similarly, you are responsible for having the binaries available in your runtime, otherwise the class initialization might fail.
5. In the lombok testing code, we used to have a version that contains this vulnerability, but since the tests don't process any user input (the tests are hardcoded) and the generated code isn't even executed, running the tests did not lead to an RCE on the machine executing the tests.

So, no, Lombok itself does not need any changes, and is not responsible for any security problems your product might have regarding these broken Log4j libraries.

Mitigation

1. Please follow the guidelines provided in the original CVE page to find out if your product is affected. Alternatively, our partner Tidelift has a great advisory
2. Upgrade your Log4j dependencies to at least 2.16.0
3. If that's not possible on short notice, here are some pointers on how to make an older installation secure

Feedback

If you do not agree with the current assessment, please add a comment to this issue. However, please make sure you've read the other comments, and make sure you understand the problem.

The balancing act:

• Don't waste our time by asking more questions that you could have figured out yourself
• Do speak up if you are convinced we missed something, or new information is available

Latest changes

• 2021-12-17 18:00 CET: Changed the recommended version from 2.15.0 to 2.16.0
• 2021-12-12 01:14 CET: The dependency used in the tests has been updated. Before that, since it was only used in tests, no user input was possible and the generated code was not executed, Lombok was already secure. But now, even external tools that analyse our code can also see that. We hope that that reduces the number of questions on our mailing lists and issue tracker.

[lidiop]

Lombok uses this framework behind the scenes: https://logback.qos.ch/
And there is the vulnerability: https://jira.qos.ch/browse/LOGBACK-1591
I am looking for a way to update my lombok, or even the logback.
Does anyone have the same question?

[rspilker]

@lidiop Lombok does not use logback or any other logging facade or backend.

Lombok does generate code, the user needs to provide the accompanying facade during compilation and facade and backend at runtime.

There is no need to update your Lombok.

[lidiop]

great @rspilker . Thank you so much for the answer.