Security

(900 words) May 2024 – Loren Kohnfelder

We understand software security best through specific threats and mitigations, articulated by threat models shared openly. Without this context we avoid much needed meaningful security discussions.

[Read More]

In the Afterword of my book I mention Ken Thompson’s classic “Trusting Trust” paper showing how to embed a backdoor into an OS by compiling the compiler such that the modification is invisible in source code.

In Chapter 5 of the book I write about my good fortunate meeting two of the RSA algorithm inventors at MIT, and collaborating with them. As soon as I had a chance to ready their (as yet unpublished) paper, the “reblocking problem” bothered me as a rather awkward implementation detail. This refers to a technical issue described in Section X (Avoiding “Reblocking” When Encrypting A Signed Message) of the foundational RSA paper that is described in a nutshell in the first sentence.

With Log4j very much in the news, if I could update my new book by magic it would make a terrific real world example to write about because it ties together a number of topics in the book. This vulnerability stems from failure to sanitize untrusted inputs, enabling an injection attack that potentially can access arbitrary targets using authentication credentials held by the target server. All the attacker has to do is craft an attack string that manages to get logged somehow, and the widely used Apache Log4j 2 component executes whatever the attacker commands.

A wicked problem is one that is difficult to even clearly describe because of its diffuse and interconnected nature, and this is a useful lens to view software security. How are we doing overall at software security? How do you even define the standard to measure against?

Spilled coffee beans, breaking the sound barrier, and software security

The Right Stuff is Tom Wolfe’s popular history of the US astronaut program, and it begins by recounting the early effort to break the sound barrier which involved such frequent crashes that there were weekly funerals for test pilots. What’s most striking about the account of this early period in what would become the space program is how the pilots gathering to bury their comrades would invariably talk themselves into believing that they would never have crashed — it was always the other guy who messed up and sadly paid the price.

One big learning for me from writing a book on software security is realizing the importance of context to security. There was a constant challenge of discovering the right scope — what needs adding, and what can be cut to keep it concise. Each chapter of the book could well have been an entire book itself, but nobody is going to read what would consume a foot of shelf space. Software security can go wrong in so many ways that there is always more to say, different approaches to take, various pros and cons of different mitigations, further interesting details to consider. And of course new vulnerabilities keep popping up, offering more examples to learn from, and suggesting various new mitigation techniques that might have prevented the problem.