61–70 of 209 posts
Clone Git Repo... CTRL+F "log4j"... 0 results... (sigh of relief)... :|
Really should run `mvn dependency:tree | grep log4j`
I'm curious about the disclosure of this vulnerability and why it seems that no prior notice appears to have been given by the researcher who published it. Is it because it was already being exploited in the wild?
as I understand, if we are running Java 8u121 this is not an issue... or is it? that's what the CVE ( https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4422... ) says: > protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
As I understand it that prevents the RCE, but not other variants like leaking environment variables.
I'll google/search more about these. I assume if we say RCE is a 10 for risk, then maybe others are 5 or 3?
I'm curious about the disclosure of this vulnerability and why it seems that no prior notice appears to have been given by the researcher who published it. Is it because it was already being exploited in the wild?
Incidents like this remind me that it is sometimes OK to ignore those who constantly order you to "vendor it out" over some notion of principled development excellence wherein one never reinvents a single hypothetical wheel. Arguably, writing text to a log file on disk is a simple thing you dont want to keep implementing over and over. But, it is also a simple thing that doesn't take a whole lot to do correctly in many use cases.
DIY (in aggregate) would represent one of the largest barriers to any attacker producing a wormable/DDOS exploit of this log4j-style vulnerability. Imagine ten thousand plus unique implementations for how to get a string to disk and I can almost assure you that not one of them would contain an attack vector like this. Even if one of them did, the other 99.999% of implementations would be unaffected and nothing would have made the headlines.
Depending on the code paths that others have developed is the biggest liability in all of software engineering. We are going to have to get better at evaluating this cost relative to the benefits. This doesnt stop with Log4j. There are other things more ubiquitous and more complicated out there still. IMO, the best we can do is to stop producing new software that is exposed in these ways.
as I understand, if we are running Java 8u121 this is not an issue... or is it? that's what the CVE ( https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4422... ) says: > protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Also, 8u121 was an incomplete fix, the complete fix (still with limitations as noted above) is in 8u191 (see second link above).
Earlier 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)
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.
> protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Generally, 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
I have taken some flak over the years for rolling my own basics like logging, telemetry, tracing, authentication, session management, etc... Incidents like this remind me that it is sometimes OK to ignore those who constantly order you to "vendor it out" over some notion of principled development excellence wherein one never reinvents a single hypothetical wheel. Arguably, writing text to a log file on disk is a simp…
I mean SQL injection is such an easy known mitigation yet is still on the OWASP top 10 even after so many years.