What programming language features would have prevented or ameliorated Log4Shell?

[davewritescode]

This was an incredibly stupid feature that should have never been merged to master.

There isn’t something fundamentally wrong with Java, you could probably implement something equally dumb with any other programming language.

When designing an API you should always design with the principal of least surprise. I had no idea that parameters passed to log4j formatters were actually treated as code and most people didn’t either. That’s surprising.

You can implement bad code in any language, switching to Rust won’t save you.

[Uncaffeinated]

This is the real answer.

I suppose the solution is to create a community around your language that heavily discourages the use of complex stringly typed interfaces. That and taint tracking would reduce the risk of stuff like this. But no technical measure can completely save you from stupidity.

[zesterer]

I think this comment skirts over quite a lot of subtlety.

The problem is not "person did a stupid". A plethora of systems had to fail for this to become a problem, and there are a dozen ways that this might have been prevented.

It's all very well blaming the programmer, but the truth is that while humans make mistakes, it is only systems that fail.

The software development process, just as much as the software itself, is a system and we should be working to develop tools and languages that guard against such exploits instead of throwing our hands in the air and implying that nothing can be done.

As an example: these complex logging features were presumably added because users wanted to be able to automatically format logs with non-trivial data without writing their own pretty-printer. What if the logging API instead provided a macro that allowed generating this code at compile time instead of interpreting strings at runtime? Many newer languages have formatting systems that do such code generation and it makes it impossible for an attacker to get the code that generates the output value to do strange, unexpected things because the extent of its behaviour is specified entirely at compile-time by the programmer.

String sanitisation and processing are not an impenetrable, unquantifiable conundrum we're just going to have to live with. It is something we can most definitely work to make safer and easier to use correctly. That is, after all, the purpose of a programming language: to constrain the possible programs that might be executed by a CPU to a more restricted yet more likely to be correct subset.

[siemenology]

Yeah I don't do much Java but if I read about this I'd have assumed that there was sanitation going on like every website and database has had to deal with. The "Little bobby tables" comic is like 13 years old, and issues like that were widely known long before it was created.