By the way, does java.util.logging still suck enough to justify the existence of all these different logging frameworks?
Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
151–160 of 209 posts
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#152Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#153Earlier quoted context omitted.
> 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.
> I spent some time looking over the source code and cannot fathom why something that logs information would need to become this complicated. That's easy: because software development is complicated. If you look at the ticket where this was added[1], it seems like a reasonable request for something a very featureful logging library might do. Other logging frameworks[2] already supported this feature. It's easy to arm…
Yet the exact same kind of feature for Logback requires _explicit opt-in_ on the part of the application developer, via a system property (`logback.ContextSelector=JNDI`) that _must be set before Logback is first instantiated_. If you want custom behavior then you, the application developer must write extra configuration or even code in order to wire Logback into your system correctly. Logback doesn't attempt to make this work for everyone for everything. It's a library. Log4J implemented the same thing and tried to make it Just Work for everyone. Unfortunately, that "everyone" includes people who are not even legitimate end-users of the application. Make the hard cases "possible", don't try to make them "easy" (especially not without several solid use-cases around "hard-but-should-be-easy".)
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#154Strange the cheat-sheet does not list setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true as a mitigation, which supposedly works for log4j versions >=2.10.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#155Not 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…
> whatever it returned would just get inserted as a string into the log output, no big deal.
Once you can inject anything that gets resolved, you have an information disclosure vulnerability unrelated to the RCE.
If I can just DNS resolve any ${env} variable from the JVM, a lot of systems are compromised by just exposing the env or system variables configured for runtime.
Just getting your $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY env vars can compromise your bucket (sure, that is a really unsafe setup now, but it was almost the standard a few years ago over configuring it explicitly).
So a logging system which will merely resolve a hostname derived from a variable was bad enough to compromise many systems.
The serialization loophole was fixed in a jdk8 update.
https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71...
But even with that in place, the information disclosure of java System or env properties is bad enough to break actual systems in prod.
This is actually next level exposure, but I saw people trying to identify Tor node IPs using this method and geolocate them.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#156Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#157Earlier quoted context omitted.
but? It think it's far deeper than mitigation, it's the solution. Edit: I apologize for getting 'sanitation' wrong. Don't do it.
The proper solution to SQL injection is parameterized queries, not input sanitization, to my knowledge.
The irony here is that if you use the log4j equivalent of parameterized queries, parameterized logging strings, you're still vulnerable to this CVE, even if you did everything right.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#158This might be a stupid question, but is it possible to airgap all classes running in the JVM from the network except for those you trust? For example, I want to block all classes from opening sockets except those in my.company.domain.* packages.
Yes, it's called a firewall. Anybody developing high security applications should limit outbound connections from their production servers to what's absolutely necessary.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#159I 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…
[deleted]
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#160I 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…
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.
Logging isn't an application that typically results in RCE (outside charlatan code, and yes I'm referring to people who call themselves senior enterprise architects).