Skip to content
0:00 / 0:00

#langsec#formalgrammars#inputvalidation

28c3: The Science of Insecurity

28c3

5.5K subscribers • 4 videos on Hallway

YouTube
  • Recommended by 12 people: 9 on Hacker News, 1 on Lobsters, 1 in engineering communities and 1 curated list.
  • A classic. People kept recommending it from 2012 to 2024.
  • Presented by Meredith L. Patterson and Sergey Bratus
  • An opinion. It argues one side of a question engineers disagree on.

Advanced. Deep dive for people who know the field.

42K views14 years ago12 recommendations

SecurityComputer scienceWeb and application securityComputation and complexityCompilers and interpreters

Meredith L. Patterson and Sergey Bratus argue that software insecurity stems from poorly defined input languages and advocate for language-theoretic security.

Download high quality version: bit.ly/uSJPUL Description: events.ccc.de/congress/2011/Fahrplan/events/4763.en.html Meredith L. Patterson, Sergey: The Science of Insecurity 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. In this talk we'll draw a direct connection between this ubiquitous insecurity and basic computer science concepts of Turing completeness and theory of languages. We will show how well-meant protocol designs are doomed to their implementations becoming clusters of 0-days, and will show where to look for these 0-days. We will also discuss simple principles of how to avoid designing such protocols.

Why it's here

12 people recommend this

What people say. Highly recommended as a foundational talk on language-theoretic security and secure input parsing.

u/mattman59in r/netsec • Recommends

28c3: The Science of Insecurity (1 hour video lecture)

jdietrichon Hacker News • Recommends

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. link to this video

sedachvon Hacker News • Recommends

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: link to 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.

Sietsebbon Lobsters • Recommends

The Science of Insecurity (Meredith L. Patterson, 2011) (Sorry, I couldn't find a transcript. Here's the opening paragraph, though.) "This talk is about the science of insecurity, by which I mean the entire spectrum of exploits and vulnerabilities considered as a systematic, repeatable, and most importantly, predictive mathematical model. We're going to examine, from first principles, what it is about exploits that makes them exploits in the first place, and how we can use this systematic understanding to design and implement software in which - t…

programming-talkscurated list on GitHubRecommends

Under “Security”

28c3: The Science of Insecurity 00:59:22 by **Meredith L. Patterson, Sergey** (2011)

mknon Hacker News • Recommends

On “Tanenbaum’s advice for building product, networks, and living life. ”

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

TeMPOraLon Hacker News • Recommends

On “Comments in JSON”

…e 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 link to 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.…

majikaon Hacker News • Recommends

On “Bytecode”

This is related to Meredith Patterson's talk at the 28th CCC, "The Science of Insecurity": link to 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…

noblethrasheron Hacker News • Recommends

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: link to this video (around 19:00 is especially entertaining)

ShaneWiltonon Hacker News • Recommends

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 link to this video 3 link

hannobon Hacker News • Recommends

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: link to this video

holmesworcesteron Hacker News • Recommends

On “Civil society in Latvia, Lithuania, and Poland targeted with Pegasus spyware”

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 solu…

zitterbewegungon Hacker News • Mentions

On “MVC, MOVE - Or Simply A State Machine?”

An even better argument for a state machine (FSM or PDA) * link You can basically make security proofs in your protocol. link to 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.

noblethrasheron Hacker News • Mentions

On “Language-theoretic Security”

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

dom0on Hacker News • Mentions

On “Language-agnostic schemas based on Haskell's type system”

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

sedachvon Hacker News • Mentions

On “I Quit My Job to Live on Donations to Zig”

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: link to this video