Hacker News Reader

Comment by nrdvana | Hacker News Reader

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.

View on HN

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.

It's not just the library. It's the entire culture surrounding Java. The language itself is fine, but Java culture is brain dead.

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.

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.

> 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.

> 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.

Reply on news.ycombinator.com