Conversation

Replying to
It also interprets them in the strings being passed as parameters rather than only the main format string itself. It's not even avoidable by avoiding passing attacker controlled format strings. They're trying to put a bandaid on a fundamentally broken and horrifying design.
2
5
Yeah, my initial reaction reading the "Lookups" feature page was "why does this exist? None of this is supposed to end up in logs?" But I thought they had at least disabled the feature by default in the new version. Though not by introducing a new "really enable" config...
1
3
They tried to take the horrifying SQL escaping approach from PHP and screwed it up. They've already had to release a 2nd release candidate attempting to fix it. I doubt they've done it properly and there are further issues beyond what they're filtering.
Quote Tweet
If you already upgraded code to use just released log4j-2.15.0-rc1, it's still vulnerable - you now need to apply log4j-2.15.0-rc2 as there was a bypass. They is no stable release which fixes yet.
Show this thread
2
4
Given that it has built-in support to leaking environment variables (and the amount of services that still provide secrets that way) which I think was not fixed by the patch, the only reasonable course of action really does seem to be "burn it with fire".
1
1