28c3: The Science of Insecurity

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

Did your programs take input? If you had studied parsing theory, you would know that "strings" do not mean ASCII/Unicode text strings, they mean sequences of symbols from a set. All communication protocols, any kind of input, can be described in terms of grammars, and that is important: ▶ this video

▶ this video i.e. it's kinda unwise in some applications (e.g. arbitrary / untrusted schemas) to have to implement & run languages that are powerful enough to perform pretty much arbitrary computation.

> 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.

It's kinda interesting that he writes a long blogpost with many ideas that are quite similar to the Langsec ideas, however in the comments he says that he wasn't aware of Langsec. I am not surprised. Langsec could really be a gamechanger in many aspects of IT security, yet many people in the Infosec community are not aware of these concepts. If you're curious, this older talk by Meredith Patterson is still worth watching a lot: ▶ this video

Langsec knows all about type theory: See ▶ this video (about 90 seconds) n.b. that Merideth Patterson, the speaker in that video, is one of the original authors of langsec.

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

Yes, I should have said “unbounded length field”. But, with respect to the discussion, a 32 or 64-bit integer is only bounded in the academic sense. Also, here is a video that works a bit better as an introduction to LANGSEC: ▶ this video (around 19:00 is especially entertaining)

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.

> "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.

Meredith Patterson's astonishing CCC talk on computing and linguistics. It's a tour de force, presenting a systematic and practical proposal for how we can build an open and secure future for computing. I can't imagine a better example of the joys of inter-disciplinary thinking. ▶ this video

An even better argument for a state machine (FSM or PDA) * link You can basically make security proofs in your protocol. ▶ this video I was thinking about extending this to bottle.py and replacing the routing elements with an fsm library. Then I wanted the views to be a bunch of regexps or simple includes.

Item [8] was mentioned in this talk: ▶ this video by Meredith Patterson. She contends, and it seems sound to me, that the time has passed to be "tolerant when accepting," and that you should instead only accept regular grammars or, at worst, context-free grammars as input languages on the open Web.