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.

Each time a high-profile software security bug is reported, I wonder how this happened yet again. I don’t expect vulnerabilities to approach zero any time soon, but still I’d like to know how this keeps happening over and over, so we can do better. For example, was a developer unaware of the implications of their code change that broke security, or did they know but were just sloppy? How do these bugs get past a code reviewer, or was that considered unnecessary and skipped? Why weren’t there test cases to prevent such problems? And once we get a fix, how was it tested, and did anyone check for similar vulnerabilities that might exist elsewhere in the code? We can’t make much progress if we don’t know why well-known countermeasures aren’t working.

I believe that we can do so much better at delivering more secure software, and my book explains how we could do that. While there are a few new ideas in there, it’s mainly about covering well established methodology with focus on showing how to put it into practice. The book takes a different approach to the topic of software security to reach as broad an audience of software professionals as possible because I think there is often an over-reliance on “experts”.

In the book Project Hail Mary by Andy Weir, there is a short scene (on page 339) that features a very clear example of failure to implement Complete Mediation (one of the secure design patterns described in Chapter 4 of my book).