Hacker News Reader

Comment by phkahler | Hacker News Reader

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 how something is going to do what they want and not really consider ways to abuse it. But this was documented and in plain sight if you think about it.

View on HN

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.

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.

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

You're right. I probably wanted to excuse my own guilt ;-)

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

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

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.

The patch seems to be disabling the feature by default. Not a great fix.

Reply on news.ycombinator.com