28c3: The Science of Insecurity

What Hacker News said

Strong rec jdietrich · 2013-04 · on “Ask HN: What's the best technical talk you've heard?”

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]

Strong rec sedachv · 2016-05 · on “Remote code execution vulnerability in ImageMagick”

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

Recommends mkn · 2012-03 · on “Tanenbaum’s advice for building product, networks, and living life. ”

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.

Recommends TeMPOraL · 2013-08 · on “Comments in JSON”

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

Recommends majika · 2013-11 · on “Bytecode”

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

Recommends noblethrasher · 2015-01 · on “Useful old technologies: ASN.1 (2013)”

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)

Recommends ShaneWilton · 2015-07 · on “Hammer: Parser Combinators for C”

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]

Recommends hannob · 2015-11 · on “We need less powerful languages”

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]