28c3: The Science of Insecurity

> 1. Simpler formats for file representation and data interchange. When someone tries to add an extra bitfield option, say no. When they keep trying, get a wooden stick with "no" written on it. Part of the disease of modern computing is bloated specs. > 2. Restrictive not permissive code bases. Exit and bail out early. Tell the user "file corrupted". Push back. The best talk on computer security I have seen is Meredith Patterson's Science of Insecurity at 28c3: [this video] It is really interesting that the techniques needed to achieve these security goals (theory of grammars) is one of the oldest and best explored areas of computer science.

> "Code" requires some notion of an execution platform/environment, which does not exist for arbitrary data. Arbitrary data don't exist without some notion of an execution (or interpretation) platform. We tend to use "code" as a word for "commands telling some execution process what to do" and "data" as a word for "information that is meant to be transformed" but in reality this distinction is meaningless; both are fundamentally the same thing, and even our "code" vs. "data" words have blurry borders. It's very apparent when you start reading configuration files. For example, aren't Ant "configuration files" essentially programs[0]? We all know what we usually mean in context by saying what is "code" vs. what is "data", but one has to remember, that in fact they are the same - minding it leads to insights like metaprogramming. Forgetting about it leads to dumb languages and nasty problems, and is generally not wise. [0] - the answer is: yes, they are, see [link] for more. ETA: Questions to ponder: - are regular expressions code, or data? - is source written in Prolog code, or data? Also I recommend watching [this video] to learn how what would be data, as defined by formal grammars of some real-world protocols, can - by means of sloppy grammars and bad parser implementation - cross the threshold of Turing-completeness and become code.

This is related to Meredith Patterson's talk at the 28th CCC, "The Science of Insecurity": [this video] > Why is the overwhelming majority of common networked software still not secure, despite all effort to the contrary? Why is it almost certain to get exploited so long as attackers can craft its inputs? Why is it the case that no amount of effort seems to be enough to fix software that must speak certain protocols? > The answer to these questions is that for many protocols and services currently in use on the Internet, the problem of recognizing and validating their "good", expected inputs from bad ones is either not well-posed or is undecidable (i. e., no algorithm can exist to solve it in the general case), which means that their implementations cannot even be comprehensively tested, let alone automatically checked for weaknesses or correctness. The designers' desire for more functionality has made these protocols effectively unsecurable.

Hammer is a nifty parser combinator library from the people behind Language-Theoretic Security [1]. Their goal is to promote the use of context-free formats and protocols, to avoid falling into the trap of trying to parse recursively-enumerable languages, a problem that reduces to the halting problem. The idea is that by sticking to context-free grammars, protocols will be easier to parse, and the bulk of memory corruption errors can eliminated. Meredith Patterson and Sergey Bratus gave an excellent talk on the subject at 28c3 [2], and they've put together a video series on using Hammer to build a secure parser for JSON RPC [3]. [1] [link] [2] [this video] [3] [link]

I think a lot of people are mis-seeing these Pegasus attacks as a problem of political will ("we need sanctions on NSO/Israel!") or memory safety ("rewrite it in Rust!") when there is a deeper problem: parser complexity. Specifically, we're using context-sensitive and Turing-complete parsers up and down the software stack, which (at the Turing-complete level of complexity, says Gödel) guarantees that determined attackers can expect to discover an exploitable "weird machine." Folks should watch this panel and other talks by Meredith L. Patterson (co-collaborator and wife of the late Len Sassaman) and Sergey Bratus (previously at DARPA, now Dartmouth) to get a sense of the problem and the solution. [link] These folks are saying that, just as the industry handled over-the-wire insecurity with TLS and e2ee (and not rolling our own crypto) we can handle device exploitability with well-described data and automated parser generation from those descriptions (and not rolling our own parsers, which these folks say should be verboten for the same reason as rolling one's own crypto: parsing is too hard for non-specialists to get right). Moreover, we don't have to redo the whole stack for it to be meaningful: big players can start using this tooling (e.g. [link] ) for parsers handling data from very untrustworthy inputs, such as message payloads sent to a phone number. Apple's Lockdown mode is a step in this direction, though in such a crude, "burn the village" way that it makes the phone