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

71–80 of 209 posts

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

#71

Post by Johnny555 »

bob1029 wrote: post #66

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…

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.

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

#72

Post by modoc »

pageandrew wrote: post #65
ridaj wrote: post #62

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?

> 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

It was being exploited in the wild at least as early as Dec 1st (based on log analysis I've seen). The rate of attempted exploits went WAY up after the 9th.

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

#73

Post by bostik »

cmelbye wrote: post #59
staticassertion wrote: post #38

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

IIRC Cloudflare said the earliest they had seen this being exploited in the wild was very early December, but the volume went up after Friday.

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

#77

Post by layer8 »

bcrosby95 wrote: post #53
layer8 wrote: post #36

Earlier 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…

The main design mistake is including it, by default, in the first place, rather than requiring you to specify some kinda custom appender or whatever. The idea that a logging framework could lead to an RCE like this is completely bonkers. The vast majority of users just want to log straightforward data.

I think it’s okay to allow specifying such substitution variables in the log pattern syntax specified in the logging configuration, but not interpreting the log message strings provided by the application, and certainly not on log message parameters.

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

#78

Post by tester756 »

Johnny555 wrote: post #71
bob1029 wrote: post #66

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…

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.

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

#79

Post by artificialLimbs »

klysm wrote: post #15
ronnier wrote: post #12

Are there any notable systems exploited by this besides minecraft?

Unifi systems is a pretty bad one

UBNT says the Unifi Network app is unaffected, but they are patching "out of an abundance of caution"... whatever that means.

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

#80

Post by ollien »

thinkmassive wrote: post #58
layer8 wrote: post #36

Earlier 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)

Correct me if I'm wrong, but this means that an application with version 2.15 installed can still be vulnerable, yes?
Post reply on HN