28c3: The Science of Insecurity

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. [VIDEO]

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

Item [8] was mentioned in this talk: [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.

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

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: [VIDEO] (around 19:00 is especially entertaining)

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] [VIDEO] [3] [LINK]

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: [VIDEO]