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

161–170 of 209 posts

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

#161

Post by throw_m239339 »

phkahler wrote: post #149

After reading about this Log4j thing I realize it's not a bug. The vulnerability is due to a feature being exploited by the attacker. I'm not even going to qualify that by saying "exploited in unexpected ways" because it's being used exactly as intended. It seems the people who added and use that feature never took the time to ask "how can this be used nefariously?" That's not a criticism, most developers focus on ho…

> After reading about this Log4j thing I realize it's not a bug.

It's an exploit and shouldn't be a "feature" at first place.

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

#162

Post by mumblemumble »

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…

To take the example of log4j, I can see this going two ways.

On the one hand, I've worked at a couple places that used homegrown logging, and it's been fine. They covered all the features I use/want out of a logging framework, in only a couple hundred lines of code. I suspect that both logging frameworks even had lower TCO than their respective platforms' name brand loggers, because the greater simplicity paid recurring dividends across the whole organization.

I suspect, sometimes, that arguments against DIY being too complex have an unstated major premise that you need to implement a significant fraction of the off-the-shelf library's features. In my estimation, it's more like 10%, and then the code is only maybe 2-3%, because you also don't need any of the code for managing how the features you do need interact with all the features you don't need.

On the other hand, it's not like not using something like log4j yourself is any protection from things like this. We don't use log4j where I work, but I've still had my hands full dealing with all the other software we use that relies on it.

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

#163

Post by beebmam »

phkahler wrote: post #149

After reading about this Log4j thing I realize it's not a bug. The vulnerability is due to a feature being exploited by the attacker. I'm not even going to qualify that by saying "exploited in unexpected ways" because it's being used exactly as intended. It seems the people who added and use that feature never took the time to ask "how can this be used nefariously?" That's not a criticism, most developers focus on ho…

That should be taken as a criticism. Security is critically missing from consideration in many designs.

In my experience, many teams have a "security" person that they rely on to make security judgements. That's broken. Security should be thought about by everyone, especially in a world with so many malicious actors (and growing)

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

#164

Post by taeric »

phkahler wrote: post #149

After reading about this Log4j thing I realize it's not a bug. The vulnerability is due to a feature being exploited by the attacker. I'm not even going to qualify that by saying "exploited in unexpected ways" because it's being used exactly as intended. It seems the people who added and use that feature never took the time to ask "how can this be used nefariously?" That's not a criticism, most developers focus on ho…

I'd reluctantly agree with you if it was safe to 'log.debug("{}", data)'. My understanding, though, is that is also impacted.

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

#165

Post by go_elmo »

beebmam wrote: post #163
phkahler wrote: post #149

After reading about this Log4j thing I realize it's not a bug. The vulnerability is due to a feature being exploited by the attacker. I'm not even going to qualify that by saying "exploited in unexpected ways" because it's being used exactly as intended. It seems the people who added and use that feature never took the time to ask "how can this be used nefariously?" That's not a criticism, most developers focus on ho…

That should be taken as a criticism. Security is critically missing from consideration in many designs. In my experience, many teams have a "security" person that they rely on to make security judgements. That's broken. Security should be thought about by everyone, especially in a world with so many malicious actors (and growing)

Couldn't agree more. In the end security is a critical specification just as the intended use. So then why is this kind of thinking not pushed harder? Its at least as critical as program correctness testing in the end and should therefore be treated similarly.

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

#166

Post by shoto_io »

throw_m239339 wrote: post #161
phkahler wrote: post #149

After reading about this Log4j thing I realize it's not a bug. The vulnerability is due to a feature being exploited by the attacker. I'm not even going to qualify that by saying "exploited in unexpected ways" because it's being used exactly as intended. It seems the people who added and use that feature never took the time to ask "how can this be used nefariously?" That's not a criticism, most developers focus on ho…

> After reading about this Log4j thing I realize it's not a bug. It's an exploit and shouldn't be a "feature" at first place.

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

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

#167

Post by shoto_io »

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…

Exactly. Judging a decision solely by the outcome is called "resulting" and should be avoided.

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

#168

Post by unixbane »

ineedasername wrote: post #125
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.

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

youre doing something incredibly wrong if there is a threat that your system can be taken over by logging. and java enterprise object store late bound remote naming system registry garbage non-solutions to non-problems are the thing that is being done incredibly wrong here. your opinion is literally just an admission that you misunderstand basic software engineering principles like pretty much all programmers

edit: on second thought, your sentiment makes sense in your world where most programmers live where most libs are doing asinine stuff because some enterprise dude needs it for his use case which could have been solved 500 other more saner ways. in that world, yes, you should always be afraid of anyhing, even a printf (hint hint DOTS soon)

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

#169

Post by bink »

phkahler wrote: post #149

After reading about this Log4j thing I realize it's not a bug. The vulnerability is due to a feature being exploited by the attacker. I'm not even going to qualify that by saying "exploited in unexpected ways" because it's being used exactly as intended. It seems the people who added and use that feature never took the time to ask "how can this be used nefariously?" That's not a criticism, most developers focus on ho…

In cases like this I think it's usually a collection of changes that result in the vulnerability. Someone adds support for format strings in a config. Then later someone else says "hey, what if we expanded format string support so that they can be interpolated in log strings" and at that time this didn't present a risk since the strings didn't support commands. Then someone else says "wow, what if we added support for commands to our format strings", not realizing that they now are also interpolated in log strings.

I'm not saying this is exactly what happened, but I've seen it often enough.

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

#170

Post by throw_m239339 »

shoto_io wrote: post #166
throw_m239339 wrote: post #161

Earlier quoted context omitted.

> After reading about this Log4j thing I realize it's not a bug. It's an exploit and shouldn't be a "feature" at first place.

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.
Post reply on HN