3 ms·

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 qual

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.

throw_m239339 5y ago
> 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.
- shoto_io 5y ago
  It does matter, because it helps to think about how to prevent these things in the future.
  - throw_m239339 5y ago
    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.
    - shoto_io 5y ago
      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.
      - throw_m239339 5y ago
        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.
    - phkahler 5y ago
      The patch seems to be disabling the feature by default. Not a great fix.
beebmam 5y ago
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)
- go_elmo 5y ago
  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.
- phkahler 5y ago
  >> 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 ;-)
taeric 5y ago
I'd reluctantly agree with you if it was safe to 'log.debug("{}", data)'. My understanding, though, is that is also impacted.
bink 5y ago
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.

throw_m239339 5y ago

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

shoto_io 5y ago
It does matter, because it helps to think about how to prevent these things in the future.
- throw_m239339 5y ago
  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.
  - shoto_io 5y ago
    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.
    - throw_m239339 5y ago
      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.
  - phkahler 5y ago
    The patch seems to be disabling the feature by default. Not a great fix.

beebmam 5y ago

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)

go_elmo 5y ago
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.
phkahler 5y ago
>> 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 ;-)

taeric 5y ago

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

bink 5y ago

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.