181–190 of 209 posts
Not a Java programmer, I still don't really understand how the ability to inject a JNDI lookup to your sever results in an RCE. OK, an attacker can inject a JNDI lookup, and can control what the JNDI lookup via LDAP returns... I would have thought that whatever it returned would just get inserted as a string into the log output, no big deal. But a remote JNDI lookup can return code that gets executed on the local sit…
Earlier quoted context omitted.
I don't think that's necessarily (or even probably) true in this case, since the vulnerability only exists where attacker-controlled data gets logged. If a library is just using log4j for some diagnostic messages with no user data, there's no issue, right?
> if a library is just using log4j for some diagnostic messages with no user data, there's no issue, right? Depends on the diagnostic messages and how you use the library. If exceptions are being logged with any level of detail, and an attacker has the ability to provoke exceptions while varying error message content, then the thing that seems safe was just made quite unsafe. The way I would look at it - If log4j met…
Right, I would certainly include that in "user data" though. I was mainly responding to the idea that using two logging libraries is strictly worse than one: when log4j is only used for logging safe data, and another library elsewhere, this is better than using log4j everywhere.
Earlier quoted context omitted.
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 .
See the description here for the rationale why JNDI support was added: https://issues.apache.org/jira/plugins/servlet/mobile#issue/... Nobody there seemed to be aware that the log message text itself is also subject to lookup syntax interpretation and that this would be dangerous given that JNDI also allows remote code-base download and execution from the specified URL.
Ideally, 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.
Earlier quoted context omitted.
See the description here for the rationale why JNDI support was added: https://issues.apache.org/jira/plugins/servlet/mobile#issue/... Nobody there seemed to be aware that the log message text itself is also subject to lookup syntax interpretation and that this would be dangerous given that JNDI also allows remote code-base download and execution from the specified URL.
That page requires a login.
Earlier quoted context omitted.
That page requires a login.
Only intermittently, try reloading the page.
After reading about this Log4j thing I realize it's not a bug. The vulnerability is due to a feature being exploited by the attacker. I'm not even going to qualify that by saying "exploited in unexpected ways" because it's being used exactly as intended. It seems the people who added and use that feature never took the time to ask "how can this be used nefariously?" That's not a criticism, most developers focus on ho…
That should be taken as a criticism. Security is critically missing from consideration in many designs. In my experience, many teams have a "security" person that they rely on to make security judgements. That's broken. Security should be thought about by everyone, especially in a world with so many malicious actors (and growing)
You're right. I probably wanted to excuse my own guilt ;-)
Earlier quoted context omitted.
It does matter, because it helps to think about how to prevent these things in the future.
Again, the point is, whether it is a bug or not is irrelevant. It's an exploit and should be patched. If it was deemed a "feature" then it needs to be removed. There is nothing hard to understand here.
Earlier quoted context omitted.
Only intermittently, try reloading the page.
What info does your link provide that the other canonical url for "LOG4J2-313" does not? The url people usually copy&paste that doesn't require a login is: https://issues.apache.org/jira/browse/LOG4J2-313
Earlier quoted context omitted.
On the other hand, you don't know what vulnerabilities are hidden in your own code and just haven't been discovered yet, and you're one fuzzing attack away from a vulnerability being discovered/exploited.
It really depends on the code. Proprietary custom code of course is less reviewed, but can also be much simpler and have a much smaller attack surface compared to a sprawling code-base like log4j. For me the trade-off is when understanding the complete architecture and important subtleties (often ill-documented) of a third-party library takes more time than writing reasonably straightforward custom code restricted to…
That's a pretty lush habitat for gremlins.