311–320 of 531 posts
Are there any mitigations in recent JVMs? I tried reproducing this, and got the POC to hit the LDAP server, but it wouldn't load the test payload. See also: - https://github.com/tangxiaofeng7/apache-log4j-poc - https://github.com/mbechler/marshalsec - https://github.com/veracode-research/rogue-jndi Minecraft servers were being actively exploited according to various tweets.
To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…
If I have the ability to trigger execution of a process on some service, and one of the things it does is return me the logs form that process, it might be somewhat surprising to the host of that process that if I can pass in "${java:vm}" as input, the logs might leak information about what version of the JVM it's running...
What else might you be able to get a system to leak to you if you can control input and read log output?
176K LOC. For a logging library? Oh! It's for Java. It all makes sense now. (Yes, I've written in Java, and, of course, I used log4j in the project.) Just reminds me of this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Edit: Found the answer to my own Q. "Do not use String concatenation. Use parameterized message..."
176K LOC. For a logging library? Oh! It's for Java. It all makes sense now. (Yes, I've written in Java, and, of course, I used log4j in the project.) Just reminds me of this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Log4j has a stupid amount of features though, it's basically a full featured logging library, plus Filebeat and Logstash all in one lib.
Earlier quoted context omitted.
If you check the argument, one is for RMI and the other is for LDAP, if your PoC uses LDAP then you need the LDAP one, else RMI, etc.. But yes, most people probably don't have this enabled, so the only concern is a pingback in modern java.
Pingback can also include variable contents, so it's not just "they can get the IPs", but also potentially secrets and such.
Isn't it generally considered bad practice to log user controlled data (without some form of sanitization)? I think static analyzers tend to find these since they're a type of injection attack (an attacker could insert fake log lines or otherwise interfere with the log contents)
Anyone remember printf exploits? Feels strange to still be happening in 2021. I remember accidentally finding a printf exploit in an online Nintendo DS game when I was a kid, not that I knew what I was doing but it was fun to have my name be a bunch of constantly changing random numbers using %e in my online name. Sounds like the minecraft kids are having a bunch of fun with this one now :)
I love the irony here though - given how people using Java tend to think its unexploitable compared to C/C++ code. This is arguably way worse than a format string exploit. Even user sanitized data gives you full RCE. And via url headers/strings. This feels like a 1990s web era exploit, it's pretty insane.
Earlier quoted context omitted.
> A logging framework's job is to ship strings to stdout or files or something. I've seen people (including here on HN) dismiss libraries as "abandoned" when they went a year without a release. The software industry will never get bug-free, feature-complete software so long as we're selecting for the opposite.
Code is alive and there’s typically always something to do: adding tests, removing bugs, or simply paying back technical debt. If you go a full year without any releasable changes, chances are the project has been abandoned.
Logback has an interesting commit[1]: "disassociate logback from log4j 2.x as much as possible". They also updated their landing page [2]: "Logback is intended as a successor to the popular log4j project, picking up where log4j 1.x leaves off. Fortunately, logback is unrelated to log4j 2.x and does not share its vulnerabilities." Can't say I blame them. [1] https://github.com/qos-ch/logback/commit/b810c115e363081afc7…
This is such a cheap move by Logback, which comes from the former lead developer of Log4j 1. I used to like it for its technical merits: it's really much better than Log4j 1. But its development has stagnated, and it doesn't offer anything over Log4j2 nowadays. Furthermore, it's not an Apache project, it doesn't even use the Apache License, but LGPL.
That's a major plus.
On one hand I want to be more forgiving of this, because log4j is very old, and likely this feature was introduced well before we all had a collective understanding of how fiddly and difficult security can be, and how attackers will go to extreme effort to compromise our services. But at the same time... c'mon. A logging framework's job is to ship strings to stdout or files or something. String interpolation should n…
The Ware report is 60 years old. String formatting bugs are about 20 or 30.