Naw, nobody was gonna get away with the workaround for long. Auditors would be a pain in the ass until the heat death of the universe. Most people were always going to have to upgrade.
Nah, you just upgrade to 2.16.
Or just set the system property that disables the stupid feature. Has some flaw since been found in that mitigation?
Yes, it doesn’t protect against the second one. You need to upgrade to 2.16.
Thankfully the only direct inclusions of log4j in my codebase are little support services that are so old they use v1.2. Though I set that property everywhere anyway since why not.
Property only works on 2.10+. Log4j v1 also has its own CVEs, one which involves listening to a socket and one which involves JMSAppender. If you can confirm that it isn’t vulnerable to those, you’re probably OK.
Chef’s kiss to Apache for releasing 2.16 when they did. Can’t remember the last time I had my soul so thoroughly crushed.
The 2.15 CVE has been upgraded from DoS to RCE now possible
Fuckssake.
That’s it, I’m having my team go straight to 2.20. No more of this incremental fixing, we’re gonna get ahead of the game.
[In all seriousness, someone else on my team has spent a chunk of time each day upgrading log4j shit. This is kinda nuts.]
Go 3.0 or go home.
We’re already writing log5J in my group to get ahead of the problem.
Lets make it log4K, surely.
Just stop logging altogether. Problem solved! Also, no more bugs, ever!!! :D
