Irregular Circumstances — Language-Theoretic Security

Irregular Circumstances — Language-Theoretic Security consultancy: secure parsers, file-format design, and format risk assessment.

LANGUAGE·THEORETIC·SECURITY

irregular

CIRCUMSTANCES

The parser is the perimeter.

scroll

ever have your words twisted?

Tell a machine something it can read two ways, and it picks the dangerous one. Ambiguity is insecurity.

parse — two grammars, one input

"..%2f.."
   ├──▶ a literal path       ✓
   └──▶ a directory escape   ✕

inside the machine

Every input is a language — and a breach is just a parser reading the wrong one.

≈80%

of named vulnerabilities are parsing bugs.

Eliminate the class, and most of the breach surface goes with it.

language-theoretic security

Security is decided in the grammar, not the patch.

parse · validate · refuse

Accept exactly the language. Nothing else gets through — for A inputs.

The machine

irregular

CIRCUMSTANCES

Security is decided inside — where untrusted input first becomes structure.

ic@circumstances:~$ parse --strict < untrusted.input

accept ⇔ input ∈ L(grammar)

# for ALL inputs — nothing else gets through

ic@circumstances:~$ verify ∀x . safe(parse(x))

OK — no input outside the language is accepted

ic@circumstances:~$

Out in the world

Most security work starts after the code is written.

Ours starts at the theory — what is the language of this input, and can a machine accept exactly that language and nothing else? When it can, we build the parser that does it. When it can't, we tell you that, too.

What we do

People call us for one thing in four shapes.

AA new system that ingests untrusted data and has to be safe by construction.

AAn existing system that needs to handle a known format, securely.

AA new interchange format, designed to be parsed without ambiguity.

AA decision about which of several data formats carries the least risk.

Security is supposed to be boring.

We don't chase bugs. We eliminate the conditions that allow them.

Define the grammar precisely. Build a parser that accepts exactly that language. Whole classes of bugs stop being possible — instead of being patched one at a time. As Dan Kaminsky put it: entire classes of bugs simply do not exist.

The honest answer

Sometimes the answer is: this cannot be secured. Even in principle.

Not by us. Not by anyone. Some formats are ambiguous by mathematics, not by effort — and no parser can make them safe. We get paid to tell you which ones. It's the most valuable thing we sell.

The team

Contributors to Hammer and SafeDocs — and to work we can't name.

Advised by Meredith Patterson — creator of Hammer, who coined language-theoretic security.

Hammer — binary parsing without pain.Ask us about the Badness Detector.It's pretty good.

Inquire

Bring us your hardest format.

or email hello@irregularcircumstances.com