reading about the log4j vulnerability, and... why. why does a logging system have a thing that fetches a url and executes the response. why does this exist
Conversation
I'd been assuming it must be some sort of memory or privilege exploit (cue people going "see even memory safe languages are bad") but it's completely unrelated to memory. it's that log4j uses jndi which has an extremely dangerous feature built into it
2
107
strings are so bad. you know one thing that's really good about rust? signal vs formatting is parsed out of println! _at compile time_ so you can't confuse it by putting control sequences in data
3
1
133
I'm used to thinking "you might need to shell-escape log data to get rid of formatting codes" but log4j just _downloads urls and executes the response_ as a deliberate feature?
2
5
113
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
I am honestly amazed that each time I read something new about this issue somehow makes it worse.
1
3
Saw that here and confirmed it:
news.ycombinator.com/item?id=295063
It's unfortunately for the course for anything with the Apache brand.
It's still problematic even with the vulnerability fixed because you can leak sensitive variables to logs which aren't supposed to end up in the logs.
1
4
I don't think they've fully resolved the RCE issues with their initial patch. A huge disaster beyond just one mistake has been uncovered and people are going to be looking into this mess now.
Best fix is porting to java.util.logging and using logging daemon features instead...
1
3
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
There isn't really a new version fixing the issues yet but rather a 2nd release candidate that might actually stop this particular RCE vector but I'm skeptical. I looked at it and played with it a little bit and my conclusion is the whole library needs to be burned in a fire.
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
Leaking sensitive local and global variables via the basic string interpolation is pretty bad itself. I don't know if the fact that it interpolates the strings on parameters is intended but it seems like it must be and it'd require significant breaks in compatibility to fix this.