Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

techsolvency.com

Post reply on HN
Print view View original

91–100 of 209 posts

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#91

Post by flatiron »

ineedasername wrote: post #87
pageandrew wrote: post #65

Earlier quoted context omitted.

> 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.

From what I read the patch is public and when someone saw it figured it out and publicly shared it.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#92

Post by LeifCarrotson »

Droobfest wrote: post #81

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...

Log4J version 1.x met end-of-life in 2015 [1]. Of course, that's only 6 years ago, so there are still projects out there running it. It would look for -Dlog4j.format... and would not know about -Dlog4j2.format... or, hypothetically, -Dlog4j3LTS.format...

Environment variables targeting Log4J version 2.x should get the prefix "log4j2.*" [2] so the latter is correct.

In the end it doesn't really matter if you declare an environment variable that's never read, so you could define both if you're not sure which version of Log4J is used in your stack.

[1] https://logging.apache.org/log4j/1.2/

[2] https://logging.apache.org/log4j/2.x/

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#94

Post by staticassertion »

ineedasername wrote: post #87
pageandrew wrote: post #65

Earlier quoted context omitted.

> 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.

Embargoing is very tricky and often harmful. Attackers know how to catch embargo'd vulns, it's often really easy, like in the case of the Linux kernel. If attackers have advanced notice you're only hurting defenders by hiding things from them.

We know that two weeks before disclosure there are attacks using this exploit. Somehow had clearly figured it out, so hiding it was only going to cause problems.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#95

Post by Droobfest »

Droobfest wrote: post #81

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...

Replying to myself but I guess it's the second one.

https://github.com/apache/logging-log4j2/blob/04637dd9102175...

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#96

Post by Fabricio20 »

layer8 wrote: post #89
Sohcahtoa82 wrote: post #49

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.

Except this particular issue has nothing to do with LDAP! It's perfectly reproducible with RMI for example, another JNDI supported protocol. So much so that the initial RC1 patch was an IF for LDAP, and it was obviously bypassed in seconds.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#97

Post by ineedasername »

I'm not a security researcher, so I'd like to know if (probably "why") this is a bad idea:

It seems like there should be some intermediary stage between logging the vulnerability & full public disclosure. Something like a partial public disclosure that says "Hey, we have a CVSS 10 about to come down on Log4j, everyone carve out a chunk of time to get their systems fixed when we publish to full disclosure & patch."

And security & sysadmins around the world can get ready to work before exploits can get too much of a hold.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#98

Post by staticassertion »

layer8 wrote: post #86
ollien wrote: post #80

Earlier quoted context omitted.

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.

No, you are still vulnerable, even with just what we know today and we're still finding more ways to break this library.

1. Attackers can still load code in your class path.

2. Attackers can steal environment variables, VM information, system information, etc.

3. The issue isn't specific to LDAP in any way, that was just a particularly brutal way to exploit this vulnerability. There are other ways to achieve RCE.

We may find even more ways to attack this in the future. It is absolutely not a good idea to assume you're safe right now - if you have log4j in your dependency tree, you should keep a close eye on the discourse as it evolves.

edit: I'll just say that I think it's really premature to tell anyone that they're safe.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#99

Post by layer8 »

staticassertion wrote: post #90
layer8 wrote: post #25

> 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.

The routing happens before. The vulnerability is due to processing in the log4j back-end, after normal message formatting.

Re: Log4Shell Log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

#100

Post by koboll »

ineedasername wrote: post #97

I'm not a security researcher, so I'd like to know if (probably "why") this is a bad idea: It seems like there should be some intermediary stage between logging the vulnerability & full public disclosure. Something like a partial public disclosure that says "Hey, we have a CVSS 10 about to come down on Log4j, everyone carve out a chunk of time to get their systems fixed when we publish to full disclosure & patch." An…

It's a bad idea because that would leak, and then you'd have bad actors exploiting a zero-day prior to day zero.
Post reply on HN