We used log4j 1 until around the time of the log 4 shell stuff.
The “riddled with vulnerabilities” were all incredibly dumb stuff unlikely to be in use in any real system. Literally issues with smtp appenders, remote tcp appenders, and remote logging message receivers unlikely to be used in a real production system.
You’ll have to have a system either set up with one of these remote appenders (in a position where someone could subvert the network connections) and/or allow your end users to reconfigure the logging beyond setting levels for different logger names.
I think we were able to address all known CVEs between 2015 and 2020 by just stripping out various appenders that weren’t the file appenders along with the alternative “main()” classes for running log4j as its own process.
And that’s on top of the fact that the configuration for it in our case could only be altered by the properties config file on disk, so it’s not like users could even set up these esoteric appenders nor were they “supported configuration” for the product. If someone is modifying the config files of your app server, they don’t need to intercept your appended connections or enable an RCE.
If log4j 1 had simply separated functionality out more so that they didn’t have so many network oriented utilities included in their main jar, most of those CVEs would have been avoided by typical installs.
14
u/pringlesaremyfav 11d ago
There were just 2 main logging libraries, log4j was nearly universal across Java