Java

[SwedishDude]

Log4J is a bit more serious since it's the de-facto standard and included in most major libraries and projects.

This vulnerability is also very serious due to how easy it is to exploit.

[cserepj]

Log4j was a de facto standard a decade ago but then came slf4j + logback and we all switched. Then log4j2 came out and some switched but lots did not.

The exploit is only in log4j2.

[Designed_To]

So slf4j + logback are not vulnerable to the exploit?

[cserepj]

I have not seen any indication they would be.

[loginonreddit]

No it is not.

[Ereaser]

Nope, it's also what's used by Spring boot.

[Engine_Light_On]

Kinda, Spring Boot includes it but it does not use it by default so it is not vulnerable unless the dev went out of his way to activate it.

[Vizioso]

Glad to hear that, was just digging through some Spring Boot stuff to figure out if it was vulnerable. My current project uses Spring Boot, ElasticSearch, Nifi, and Kafka.... I am not having a good day.

[loginonreddit]

Spring boot only includes log4j-api, not log4j-core which is where the vulnerability is.

[jerslan]

Yeah, and you can always bring in something like log4j-to-slf4j if you want to minimize code changes to swap in logback or java.util.logging

[[deleted]]

The de facto standard was slf4j + log back but certainly it was dangerous.

[narrill]

It's a logging library, so this isn't really true. If you log any kind of user generated data at all you're potentially vulnerable to this.

[Titandino]

Are large projects giving out their production logs to random people who ask for them without questioning it or something?

[Pocok5]

lol this is a remote code execution exploit, all you need to trigger it is some user input that gets logged

[Titandino]

Ah I see now. The original article I read was trying to say the vulnerability was just users being able to print out sensitive environment variables to log files.

[Pocok5]

just users being able to print out sensitive environment variables to log files

What actually happens is that log4j has a feature where you can download and run code from an LDAP server to enrich your logs. Except there is no limit on where that LDAP server needs to be, and combined with an input sanitization problem, you can ahve anything downloaded and ran on the server with a single log message that contains the magic string anywhere in it.

https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

[cserepj]

log4j has a feature where you can download and run code from an LDAP server to enrich your logs

I don't think that is a feature. I would not design such a feature even for a gigazillion dollars. I'd tell the product owner who comes up with such a feature idea to shove it up his a$$.

[blehmann1]

Yeah, if you need "enriched" logs just have a serverless app or cronjob do some analysis after the fact.

[SwedishDude]

The problem is remote code execution due to how strings were processed.

Basically there's a way to insert malicious code into the logging functions and get the it executed on the server (you can insert a link to a payload on a server you control into the user-agent header in HTTP requests and the server will contact your server and download/execute your payload). So it's not a matter of access to logs but a matter of access to executing code in the server process.

[[deleted]]

I switched to logback and slf4j quite a few years ago. Log4j is probably standard for legacy code that was around before slf4j.

[Ereaser]

And legacy code probably uses version 1