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

121–130 of 209 posts

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

#121

Post by darkarmani »

LeifCarrotson wrote: post #92
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…

Old versions of ElasticSearch that people still use and Livy uses 1.x.

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

#122

Post by jrochkind1 »

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 site somehow? Can anyone explain this?

update this is the best explanation I've found: https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Inj...

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

#124

Post by dharmab »

bob1029 wrote: post #105
tester756 wrote: post #78

Earlier quoted context omitted.

What if there are none? It's not like library code is some magical stuff that only senior principal ninja 10x developers can comprehend Not everything is don't roll your own crypto.

> Not everything is don't roll your own crypto. Even for crypto, I have had people give me trouble for daring to use Microsoft's public & documented implementations of SHA256 and CSPRNG to derive session secrets. It's almost as if directly interacting with any crypto primitives is tantamount to rolling your own crypto these days.

But splat 20 lines of obtuse openssl commands into a bash script and no one bats an eye!

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

#125

Post by ineedasername »

tester756 wrote: post #78
Johnny555 wrote: post #71

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.

What if there are none? It's not like library code is some magical stuff that only senior principal ninja 10x developers can comprehend Not everything is don't roll your own crypto.

>What if there are none?

The problem is that "There are no bugs" approaches an unproveable statement as a codebase grows into even a modest size. It doesn't matter if you're a 10x developer or not, you aren't always going to immediately see all the implications and edge cases of a few hundred++ (at least) moving pieces the first time around with new code, and each additional piece adds a non-linear amount of complexity.

That doesn't mean you never roll your own version of something, it just means that you should either be very very good or have a lot of experience (or both) when making that decision for anything that's non-trivial. (And deciding what is/isn't trivial is its own decision too)

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

#127

Post by john37386 »

It seems to have worm like capabilities. Right now it seems to spread. Who knows what will happen after? It's a bit of race against the clock. I found this library to be used somehow. https://github.com/projectdiscovery/interactsh

They seem to exfiltrate data. If you see these files hosted in your projects, then you are probably part of it now.

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

#128

Post by bogwog »

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…

How do you decide who to trust? Those same sysadmins in the loop could exploit it on deployments at companies out of the loop.

If that happens, it might even be construed as a criminal conspiracy.

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

#129

Post by jm12345 »

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…

The number of consumers of Log4j would mean that theres not much difference, if any, between the partial disclosure and full public disclosure. Plus, whats to stop one of the partial disclosure recipients just leaking it to the rest of the world anyway?

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

#130

Post by layer8 »

Fabricio20 wrote: post #96
layer8 wrote: post #89

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.

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.

You are right, I edited my comment now.
Post reply on HN