It's horrible that the vuln is fixed in open PR, never assigned CVE, and never released fixed version unless 0day shown in wild.
Yeah and by someone who works for palantir no less - wonder how long they have been using it!?
Log4j RCE Found
471–480 of 531 posts
Re: Log4j RCE Found
#472It's horrible that the vuln is fixed in open PR, never assigned CVE, and never released fixed version unless 0day shown in wild.
1. I believe that the zero day was released before the fix 2. There's no practical way to responsibly disclose a bug in a core library
Nah there was a PR to mitigate in 2016 -> https://issues.apache.org/jira/browse/LOG4J2-2109
Re: Log4j RCE Found
#473Earlier quoted context omitted.
The fact that the first argument is interpreted as a format string even when you aren't supplying format arguments is a violation of 'principle of least surprise'. The availability of format parameters that can access environment data - let alone remotely loaded code - is a feature most people won't discover unless they go looking for it.
How are varargs implemented in the JVM ABI? Is the called function even aware of how many parameters were actually passed, or does it have to rely on the format string for that?
Turned into an object[] array.
The log4j API implements a few overloads of each log method to help avoid the implicit array allocation happening in common logging cases (no args, one arg, etc).
The call site can tell if args were provided.
Re: Log4j RCE Found
#474Earlier quoted context omitted.
These "special" strings that Log4j parse must be in the formatting string though, right? External Strings should normally be logged as parameters, not included in the format String. For example: // this is ok log.debug("user-agent={}", userAgent); // this is bad log.debug("user-agent=" + userAgent); Does this vulnerability still work on the first case? EDIT: the answer is yes, just tried it myself.
Trying to put my head around, why is this log.debug("user-agent=" + userAgent); bad?
Because the string concatenation requires allocation of a new string, which will need to be garbage collected, regardless of whether or not the log.debug actually needs it.
Using a format and args lets you call the method with only references to existing objects, no additional string needs to be allocated unless the log method actually needs to generate the string to log (and it might even be able to use streaming to output the log and never even allocate the string)
When you’re doing things like putting trace logs with all your parameters in at the top of every method call, the memory and GC pressure of generating unnecessary strings can be significant.
Re: Log4j RCE Found
#475Earlier quoted context omitted.
If "debug.log(stuffIGotFromPeer)" is dangerous, then the problem is with debug.log and not my code. Safe logging is not too high of a bar.
The point is that the first argument is the format string. debug.log("{}", stuffIGotFromPeer) should generally be safe (this bug is an example of when it isn't, though)
The format string should not allow remote execution unless explicitly tuned on either.
Logging should not be the thing you have to sanitize.
Re: Log4j RCE Found
#476Earlier quoted context omitted.
I understand that. I don’t understand JDNI, LDAP and why it ever downloads and runs remote bytecode and why was that ever considered a good feature.
LDAP is typically a behind-the-firewall protocol. At that point, in the "old school" mindset, it's considered a trusted service. Having features to automatically pick up stuff across your own network of boxes might be considered useful by many an admin.
Also, my understanding is that Java deserialization (or deserialization in general) wasn't intended to explicitly allow actual code execution, just reconstitution of an object's state from storage on disk, the network, etc. Sometimes the state of certain types of object can be repurposed to result in arbitrary code execution, but AFAIK that wasn't an anticipated outcome or design goal back in the 90s.
Re: Log4j RCE Found
#477Earlier 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.
Why would you paid back technical debt on something where you don't intend to add features into or don't have serious bugs?
This idea that it must be changing forever is literally why you can't have simple done tools. Cause they will be considered abandoned once they do that one thing.
Re: Log4j RCE Found
#478Earlier quoted context omitted.
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.
Why would you paid back technical debt on something where you don't intend to add features into or don't have serious bugs? This idea that it must be changing forever is literally why you can't have simple done tools. Cause they will be considered abandoned once they do that one thing.
So that changes can be more readily introduced when they need to be. When the next CVE comes out, you want to be able to respond to it quickly and produce a fix.
No one said the interface or functionality has to be changing forever; as I said, work includes testing and refactors, and that includes removing code. Or just fixing known bugs. I don’t know many open source projects with zero bugs, do you?
Re: Log4j RCE Found
#479Earlier quoted context omitted.
This is just stupid. Logging should not do any side effects except writing to the log.
I'm not defending Log4j, but this error can really happen to many logging libraries. All logging libraries contain some kind of template engine as a performance optimization, in order to avoid actually generating the output string (can be costly) if logging is disabled. And template engines have always been a major source of vulnerabilities.
Nowadays I guess the logging methods using lambda to supply the log string fix the performance problem
Re: Log4j RCE Found
#480Earlier quoted context omitted.
I'm not defending Log4j, but this error can really happen to many logging libraries. All logging libraries contain some kind of template engine as a performance optimization, in order to avoid actually generating the output string (can be costly) if logging is disabled. And template engines have always been a major source of vulnerabilities.
Eliding the string interpolation doesn’t necessarily have to be a feature of the logging library, the language itself can have affordances for this. For example in swift, log.debug("my name is \(expensiveCalculate(name))") doesn’t have to evaluate “expensiveCalculate(name)” unless the logger actually opts to instantiate the string (which it can skip if say, debug logging is disabled.) This is because Swift’s string i…
It's coming to Java (soon I hope):
https://openjdk.java.net/jeps/8273943