28c3: The Science of Insecurity

What people said

sedachv · 2016-05 · Strong recommendation

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

Read the original HN comment ↗

jdietrich · 2013-04 · Strong recommendation

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]

Read the original HN comment ↗

holmesworcester · 2024-05 · Recommendation

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

Read the original HN comment ↗