Conversation

Weld Poltergeist 👻
@WeldPond
For Apache Log4j remediation priority it seems the best approach right now is: 1. log4j 2.x through 2.14 - update to 2.16 2. log4j 1.x - update to 2.16 3. log4j 2.15 - update to 2.16
33
876
Daniel Micay
@DanielMicay
Replying to
@WeldPond
logback is the real continuation of log4j1 by the original developer. Most people would really be better off using the far simpler and dramatically lower attack surface java.util.logging from the standard library. Fancy processing / triggers can be done separately via rsyslog.
1
33
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
and
@WeldPond
Migrating from log4j1 to log4j2 could easily be a difficult task for a large project. Instead of taking a reactive approach and ending up with a far higher complexity and attack surface library, they should strongly consider using logback or java.util.logging. log4j2 is a mess.
3
15
Daniel Micay
@DanielMicay
Replying to
@jornfranke
and
@WeldPond
Covered by the next tweet: twitter.com/DanielMicay/st. logback's incarnation of this vulnerability was an opt-in configuration option so an attacker would need to have control of the configuration file or you'd need to be in the very tiny minority enabling such a weird feature.
Quote Tweet
Daniel Micay
@DanielMicay
Replying to @DanielMicay and @WeldPond
logback is far closer to log4j1 than log4j2 and far lower attack surface. It was only vulnerable if the attacker had control of your configuration or you set up these rarely used features. twitter.com/DanielMicay/st is really the way to go for most people. Keep it simple instead...
1
2
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
@jornfranke
and
@WeldPond
logback is essentially an improved log4j1 while log4j2 is much more complex and significantly different. I'm really recommending using java.util.logging with logback as an easier and much more reasonable choice than log4j2 for people that were using log4j1 or are using log4j2.
1