Meredith Patterson on using language to build trustworthy systems

In this episode, I talk with Meredith Patterson, a software engineer and leader of the Langsec Conspiracy. We discuss the origins of LangSec, rigidity versus robustness, and game theory as it applies to organizational approaches to security.

Here are some highlights:

The origins of LangSec

One evening I was having dinner with another fellow grad student who was doing security, and we were talking about SQL injections. He explained to me how it was possible with some web applications or HTML forms to add additional phrases of SQL in such a way that you could trick a database into executing arbitrary queries for you. He was explaining to me that people try to white list or black list against certain regular expressions to try to prevent this from happening, but it doesn’t work terribly well. I said, ‘That’s silly, because SQL is a context free language.’ This was something that was readily evident to me from all the formal language theory I’d been doing. I said, ‘Why don’t people try to white list against context free expressions instead?’ He replied, ‘What would that possibly look like?’ I said, ‘I can’t really explain it over a dinner table, so I guess I’m just going to have to go home and write some code to do it and explain it that way.’ So I did. That ended up turning into my very first ever Black Hat talk. That was 2005.

The absence of unmitigable surprise

Dan Gear, who we had as our speaker at the second IEEE workshop on language theoretic security, gives a definition of security that I absolutely love. He says, ‘It’s the absence of unmitigable surprise.’ I think that robustness falls under this definition as well. Part of security is making sure that your code is hardened against malicious inputs. If you look at the OWASP top 10 vulnerabilities for instance, the vast majority of them are going to be input vulnerabilities of one kind or another. In LangSec we argue that the way to avoid these kinds of vulnerabilities is to be definite about what input you are willing to accept, and reject everything that doesn’t fit that. It’s not a matter of rigidity for rigidity’s sake. It’s a matter of having all behavior be defined. This is honestly one reason I think functional languages lend themselves better to this approach—because it’s easier to be exhaustive about inputs. A lot of the time the compiler will warn you, but the good news is that we are starting to see systems languages moving in this directional, particularly with Rust.

Using game theory to make security better for everyone

I asked Meredith—who also studied game theory in grad school—what organizations can do when they reach Nash equilibrium, which is a game theory state where none of the players have anything to gain by changing their strategy.

My friend Quinn Norton loves to say that ‘it’s really difficult to pull out of a tailspin from the inside.’ Part of that is that it can be difficult to really see what the landscape of payoffs is. You make predictions about the payoffs of various moves you could make, various decisions you might make based on your expectations and your confidence in those expectations. Essentially your expectations and your confidence in your expectations dictate the strategy you play. To change the payoffs, you can lower the cost of adoption, or you can alter the optics. [It would help] if you could point to success stories. There’s actually one talk that I’m looking forward to at the Security conference, which is the Secure NTP talk. They got rid of a tremendous amount of attack surface in NTP just by carving off large amounts of legacy code. This is brilliant. I haven’t looked into where they are in terms of the quality of their parsing, but that might very well be something I can contribute. I think we’ll start to see more success stories of people just using basic principles.