5 ms·

Both are problems, but to me the biggest facepalm goes to log4j because anyone in their right mind should assume that log messages are untrusted input and shoul

Both are problems, but to me the biggest facepalm goes to log4j because anyone in their right mind should assume that log messages are untrusted input and should absolutely never have been parsed for control sequences. It's another prime example of Java over-engineering everything that should have been simple.

adambatkin 5y ago
Don't blame the language, blame the library. At least it's not part of the standard library - in C, if you accidentally pass a user-provided string to the first argument of printf() you could be in just as much trouble.
- TheCoelacanth 5y ago
  It's not just the library. It's the entire culture surrounding Java. The language itself is fine, but Java culture is brain dead.
- fulafel 5y ago
  There's a lot of over-engineering and tolerance of complexity in the Java world, more than in many other ecosystems, it's a pretty widely held view. The library is a product of the environment it evolved in.
thrashh 5y ago
Isn’t log input being untrusted input an opinion? Because in an alternative universe, they could have chosen to treat log messages like SQL where parameters are passed separately. Obviously some people must believe that logs should be trusted input, otherwise we wouldn’t be in this situation. That said I consider both logs and error exceptions as untrusted input, but purely on practicality.
- zenexer 5y ago
  > Because in an alternative universe, they could have chosen to treat log messages like SQL where parameters are passed separately. They did chose to do this. The vulnerability arises even when this is done correctly. Pseudocode: log("example: %s", userInput) This is still vulnerable. The parsing that exposes the vulnerability occurs on both the format string and userInput here.
fivea 5y ago
> It's another prime example of Java (...) Log4j is not java. In fact, you can have log4c# or log4rust or log4fortran with precisely the same design, and consequently the same design problems and vulnerabilities.
- deleted 5y ago
  [deleted]

adambatkin 5y ago

Don't blame the language, blame the library. At least it's not part of the standard library - in C, if you accidentally pass a user-provided string to the first argument of printf() you could be in just as much trouble.

TheCoelacanth 5y ago
It's not just the library. It's the entire culture surrounding Java. The language itself is fine, but Java culture is brain dead.
fulafel 5y ago
There's a lot of over-engineering and tolerance of complexity in the Java world, more than in many other ecosystems, it's a pretty widely held view. The library is a product of the environment it evolved in.

thrashh 5y ago

Isn’t log input being untrusted input an opinion? Because in an alternative universe, they could have chosen to treat log messages like SQL where parameters are passed separately. Obviously some people must believe that logs should be trusted input, otherwise we wouldn’t be in this situation. That said I consider both logs and error exceptions as untrusted input, but purely on practicality.

zenexer 5y ago
> Because in an alternative universe, they could have chosen to treat log messages like SQL where parameters are passed separately. They did chose to do this. The vulnerability arises even when this is done correctly. Pseudocode: log("example: %s", userInput) This is still vulnerable. The parsing that exposes the vulnerability occurs on both the format string and userInput here.

fivea 5y ago

> It's another prime example of Java (...) Log4j is not java. In fact, you can have log4c# or log4rust or log4fortran with precisely the same design, and consequently the same design problems and vulnerabilities.

deleted 5y ago
[deleted]