Are there any notable systems exploited by this besides minecraft?
My ERP, PLM and MRO vendors are all still investigating.....
I suspect we'll be patching quickly before Christmas.
Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
41–50 of 209 posts
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#42Earlier quoted context omitted.
Why would you even call that out when you don't know? Just because it uses Java does NOT mean it uses log4j. None of Jetbrains IDEs are affected btw.
They contain (among many other things) a log4j copy with the vulnerability, so saying they might be affected isn't unreasonable.
No, it is unreasonable. It's baseless speculation, which is easily disproven [0]
[0] https://intellij-support.jetbrains.com/hc/en-us/community/po...
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#43Earlier quoted context omitted.
Yeah - for example to determine if log4j is used in a maven project one would have to run "mvn dependency:tree | grep log4j". Which I did today for our 60 microservices. And also for projects deployed as war files - container server libraries also have to be checked.
It's probably worth refining it to `log4j-core`. `log4j-api` or various bridges like `log4j-to-slf4j` are not affected, but will show up in nearly any spring boot app.
Just for reference here's the posting that confirms such:
https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-s...
Also worth noting this is not log4j 1, but log4j 2, like angular vs. angularjs. Version 2 is a backwards-incompatible rewrite with a different package structure, effectively a different product. Version 1 is unaffected by this mess.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#44Earlier quoted context omitted.
"A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it. Log4j is a canonical logging utility for a huge ecosystem. Its current radius is beyond doing due diligence." - @rakyll (AWS)
Can you parse this quote for me? I do not understand it.
They didn't get my original statement because I'm a PHP dev (no compiling involved)... sigh
That being said, I do rely on containers, micro services, and other tools like Jenkins that will need eval.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#45Wouldn't this also be mitigated by better/stricter sandboxing? (specific network access, per app firewall etc)
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#46Generally, when the boss asks you which logging library your Javaland project uses, the answer is "all of them."
Discovered one legacy project which did jboss logging -> log4j-over-slf4j -> slf4j -> logback For what the project used it for, jboss logging could have been replaced with direct slf4j usage, and even if it hadn't, supports slf4j directly so that was a headscratcher
At least it avoided the current vulnerability that way. :)
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#47Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…
Apparently the intention was to add the ability to parse random crap one might wish to put in config files, including things like pulling a string out of a JNDI reference, system variables (maybe environment variables?); the person making the change did not understand that the scope extended into actual log printing as well.
I probably spend more time grepping dependencies than googling for fixes. Scope kills.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#48Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…
Personally I'd like to see more runtimes with some concept of capabilities. As a user, I'd like to be able to say "this package cannot make outbound calls" rather than doing so at the program or host grain via layer 3 or layer 7 firewall rules. I think maybe Deno allows this, and I wouldn't be surprised if JVM or .Net did as well.
Failing that, it would be interesting to see this implemented as a linter--low level I/O and HTTP functions are annotated such that callers must have the appropriate capability annotation in order to call them. This wouldn't prevent a nefarious library publisher from making HTTP requests through an FFI or an alternate HTTP library unknown to the linter, but it would prevent attackers from exploiting bugs/misfeatures in libraries as in this log4j case.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#49Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…
The main design mistake in log4j is that it performs ${…} substitution on the complete log message by default. There’s no way for application code using the log4j front-end API to have input data containing such strings be logged verbatim, without nonstandard log4j back-end configuration (someone correct me if there’s actually a way). In principle, each application has to sanitize all strings to be logged by strippin…
Why did the substitution syntax ever even allow JNDI calls?
I mean seriously, who thought this was a good idea? It's about as dumb as allowing a SQL server to execute shell commands or read/write directly to files, or for XML documents to allow external entities that can fetch from URLs or local files.
Even worse is when these gaping security holes are enabled by default.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#50Ideally, log4j should not have the ability to make "outgoing calls" right? It has been years since I used it but I can't remember a valid reason why it should be allowed to do so. Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother. It seems like having a "central" "syslog" logging server. Traffic goes from the stack -> logging serv…
> Ideally, log4j should not have the ability to make "outgoing calls" right? What is the intended scope of log4j? I spent some time looking over the source code and cannot fathom why something that logs information would need to become this complicated.
Welcome to the Java ecosystem. Please enjoy your stay.