Development quote of the week

I disagree with you, because most of these failures are not a consequence of not "rejecting such nonsense as obviously insecure", and placing more burden on the pro-bono creators of useful code to not make mistakes is not going to work - if it did, then there would not be security vulnerabilities in any software.

Look at the log4j mess as a sample. There are three things interacting, all of which are needed for a vulnerability to occur:

1. The log4j developers did not expect that untrusted input would be passed as the trusted format string. There is no way in Java (or C for that matter) to distinguish a string that can be trusted from untrusted input, so there's nothing that could be done at review time to enforce that the format string is trustworthy.
2. Log4j has a plug-in mechanism that's well-designed, and allows you to extend the set of tokens log4j interprets in a trusted format string at runtime with new code at runtime.
3. Java has a mechanism to load bytecode from a remote server, akin to loading shared libraries from an NFS mount in a traditional UNIX deployment.

The security issue is that if you didn't realise that you had (3) enabled in your Java runtime, and you ignored (1) and fed user input directly as a format string despite log4j developers telling you not to do that, then (2) came into play, and (to everyone's surprise) it was possible to invoke the remote code mechanism from a log4j format string.

Now, when the log4j maintainers realised that the combination of 2 and 3 was dangerous, they made changes that would allow you to turn on further lockdown of the plug-in mechanism so that you couldn't combine 2 and 3. As a pro-bono project, they had no contact with users, and were not sure how many combined 2 and 3 deliberately, and how many were doing so by accident; the decision they came to was to default the further lockdown to "off", to document that you should turn it on, and to change their example code to always turn it on. Unfortunately, people didn't bother with the log4j documentation, preferring to crib from other codebases, and thus never realised they were supposed to flip the switch.

The fixed release simply changes the default; if you need to combine 2 and 3, then you need to turn the switch the other way, and hopefully you'll keep on top of your code base here.

From our perspective, after the fact, the people working pro-bono on log4j made the wrong choice. They should have flipped the switches to "always safe", and required people who needed the potentially unsafe behaviour to flip the switches themselves; however, I can understand why they chose to instead avoid breaking people who'd deployed and used log4j happily, and then got surprised by the breakage.

But most of the issues were not obvious in advance - the only "obvious" mistake is leaving the defaults as "unsafe" when they could have flipped it. Given the sheer volume of abuse they got for getting it wrong, though, it seems plausible that if they'd set the default to "safe", they'd have faced abuse anyway for breaking perfectly reasonable and working deployments.