so is it:
-Dlog4j.formatMsgNoLookups=true
or
-Dlog4j2.formatMsgNoLookups=true
? Every project seems to list one or the other, even this cheat-sheet seems to list both in a random way...
Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
81–90 of 209 posts
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#82> A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it. But it’s often still possible to use a different backend, via the Log4j to SLF4J adapter: https://logging.apache.org/log4j/2.x/log4j-to-slf4j/
I believe this is the default in Spring Boot.
Logback is used by their starters (see https://docs.spring.io/spring-boot/docs/current/reference/ht...).
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#83Earlier quoted context omitted.
The main design mistake in log4j is that it performs ${…} substitution on the complete log message by default. There’s no way for application code using the log4j front-end API to have input data containing such strings be logged verbatim, without nonstandard log4j back-end configuration (someone correct me if there’s actually a way). In principle, each application has to sanitize all strings to be logged by strippin…
> without nonstandard log4j back-end configuration By "nonstandard" do you mean different than default settings? It looks like they changed the default as of v2.15: https://issues.apache.org/jira/browse/LOG4J2-3198 For earlier versions (2.10+) it looks like there's a single setting you can toggle to prevent the lookup behavior: log4j2.formatMsgNoLookups=true (or env var LOG4J_FORMAT_MSG_NO_LOOKUPS=true)
Yes, it’s good that they changed the default now. But it’s still a design mistake that they can’t distinguish between the log pattern, log message format and logging parameters. If you turn it on, it’s turned on on everything, because the substitution is performed as the last step.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#84Optimizely A/B-tested it all away it seems...
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#85Earlier quoted context omitted.
It's still very early, we won't have breach notifications for a while since any attacks would have started in the last few weeks at the earliest, and most would have started last week.
It’s possible that it was exploited before the issue was widely discovered, right? I thought it had been in there for a while.
It's entirely possible and it's still so early that we're still guessing. But so far some companies have come out to say that they've seen exploitation only as early as a few weeks ago.
Companies likely only started IR in the last week. Breach notifications, which only a minority of companies will bother to send out, will be a few weeks away at the earliest.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#86Earlier quoted context omitted.
> without nonstandard log4j back-end configuration By "nonstandard" do you mean different than default settings? It looks like they changed the default as of v2.15: https://issues.apache.org/jira/browse/LOG4J2-3198 For earlier versions (2.10+) it looks like there's a single setting you can toggle to prevent the lookup behavior: log4j2.formatMsgNoLookups=true (or env var LOG4J_FORMAT_MSG_NO_LOOKUPS=true)
Correct me if I'm wrong, but this means that an application with version 2.15 installed can still be vulnerable, yes?
Not really, because log4j now restricts JNDI-LDAP queries to localhost by default, or to an explicitly configured list of hosts. An attacker would have to have access to the application configuration or start script.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#87I'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?
> The vulnerability was privately disclosed to Apache by Alibaba's Cloud Security Team on 24 November 2021 and publicly disclosed on 9 December 2021. https://en.wikipedia.org/wiki/Log4Shell
That still seems like an extremely small window of time to remain on the good side of "responsible disclosure" for a vulnerability of this magnitude. The fix was only released 3 days before public disclosure.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#88so is it: -Dlog4j.formatMsgNoLookups=true or -Dlog4j2.formatMsgNoLookups=true ? Every project seems to list one or the other, even this cheat-sheet seems to list both in a random way...
[deleted]
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#89Earlier quoted context omitted.
The main design mistake in log4j is that it performs ${…} substitution on the complete log message by default. There’s no way for application code using the log4j front-end API to have input data containing such strings be logged verbatim, without nonstandard log4j back-end configuration (someone correct me if there’s actually a way). In principle, each application has to sanitize all strings to be logged by strippin…
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.
Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide
#90> A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it. But it’s often still possible to use a different backend, via the Log4j to SLF4J adapter: https://logging.apache.org/log4j/2.x/log4j-to-slf4j/
Does this routing happen before or after log4j would be exploitable? Like if log4j is still running its parser and doing all the crazy stuff, but then routes to some other logger, it doesn't matter.