Most Impactful:
===[ Winner:
CVE-2023-4863, the WebP 0-day
Technical details: https://blog.isosceles.com/the-webp-0day/
Comprehensive discussion in: https://www.openwall.com/lists/oss-security/2023/09/21/4
Links and materials at NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-4863
---[ Why we think this is important:
Besides being absolutely everywhere, it underscores two crucial LangSec points:
(1) Any input is a program. Huffman compression may sound like a fairly
constrained algorithm, but it is still driven by the bits of the input.
(2) Graphics formats are an attack surface. This attack surface needs to be
minimized to machine-readable machine-checkable unambiguous definitions,
from which safe parsers should be generated.
Fuzzing is not a solution (as Ben Hawkes brilliantly points out).
Sandboxing is not a solution. Algorithmic cleverness and subtlety is
not a solution.
===[ Runner-up:
"The Most Dangerous Codec in the World: Finding and Exploiting Vulnerabilities in H.264 Decoders",
Willy R. Vasquez, Stephen Checkoway, Hovav Shacham, https://wrv.github.io/h26forge.pdf
USENIX presentation: https://www.usenix.org/system/files/sec23_slides_vasquez.pdf
The tool: https://github.com/h26forge/h26forge
The h26forge tool suite is fabulous. It is probably the next best thing after a
proper mechanized definition of the format. It comes close to beginning to
empirically measure the cost of unmanaged complexity at the communication
boundary---which, as the WebP example shows, is mind-boggling even for a single,
modern implementation of a newly designed format.
The complexity and effectiveness of this tool shows the true cost of "business
as usual" in programming at the communication boundary.
===[ Aspirational: Ninja non-terminating parsing, low and slow, aspiring new bug class
The bug: https://www.cloudfoundry.org/blog/usn-5328-1-openssl-vulnerability/
Some day when we are past due diligence in format definition and parsing, and no longer
allow inputs to corrupt our memory, other classes of bugs will remain, which will need
more mathematical, logical, and proof machinery to get right. Non-termination in parsing
appears to be just such a problem. It is neither easily observed nor as easily connected
to input grammars as memory corruption. Perhaps finding this bug should be taken up as an
exemplary reaching goal for parser correctness.
From the Turing machine halting problem, we know it is undecidable to determine whether
an arbitrary program will terminate or wander through an infinity of loops and recursion. This
general result did not prevent Tavis Ormandy's fuzzer from finding one particular instance
of this problem, where a modular square root function BN_mod_sqrt() fails to terminate due
to erroneous loop arithmetic conditions over the invalidly crafted elliptic curve.
This underscores another LangSec point: fuzzing is really program analysis, although
algorithmically randomized rather than sound and exhaustive, and implicit rather than
explicit about the properties being analyzed. Yet it can and occasionally does rise
to the higher program analysis mark, which is what we see here. Can we expand this
to more bug classes?
-----
Hardest to Fix:
===[ The Winner:
LogoFAIL:
https://binarly.io/posts/finding_logofail_the_dangers_of_image_parsing_during_system_boot/
https://binarly.io/posts/The_Far_Reaching_Consequences_of_LogoFAIL/
LogoFAIL is iconic in so many ways, including "you had one job" and "you parsed what where?"
Yet the worst is that defenders are stuck protecting a terrain without a map. In a
vast and arguably least well-instrumented supply chain landscape, it's not a good position
to be in. This one truly bites.
===[ Runner-ups:
"BatBadBut" Command Injection, CVE-2024-24576
https://insights.sei.cmu.edu/blog/what-recent-vulnerabilities-mean-to-rust/
This is another reminder that parser bugs go deeper than memory safety.
This bug reminds us that we need to mind BOTH input AND output languages,
both the caller and callee languages, both the unparsers and the parsers.
The RustTLS bug has the same lesson:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-32650
Memory safety is beautiful and so is Rust; they are deep magic. Yet parser correctness
is the deeper magic.[*]
[*] Composition is deeper magic still: "Cross-Language Attacks",
https://www.ndss-symposium.org/ndss-paper/auto-draft-259/,
but we really do need to get our parsers right first!
-----
Amazing Parser Differentials and where to find them:
===[ The Winner:
https://gitlab.com/gitlab-org/gitlab/-/issues/437819,
"Subsequently the verified devfile YAML is passed on to some Go binary in the
devfile-gem. Due to YAML being a complex format the Ruby and the Go parser differ a bit
and we can construct a YAML file which doesn't seem to have a parent key in Ruby but has
one in Go."
Two memory safe languages, both alike in dignity, are disagreeing here. It is a thing
of beauty. It also drives home the point that no data format is so simple as to not
need a mechanized definition, and formats considered to be "infrastructure as code"
definitely should have one!
---[ Runner-up:
Node.js + GCP/Akamai/ATS request smuggling vulnerability caused by differences in
interpretation of carriage returns within optional whitespace in HTTP/1.1 chunk-extensions
The details: https://youtube.com/watch?v=aKPAX00ft5s&t=9919s
A brief PoC: https://langsec.org/spw24/Node_js_Parser_Differential.pdf
This bug joins a long line of classic parser differentials in the clouds such as
"HTTP2, The Sequel is Always Worse" (https://portswigger.net/research/http2). Perhaps
the clouds are actually made of parser differentials?
For a great review of cloud parser differentials, see this year's workshop's invited
presentation by Bahruz Jabiyev.
------
The Weirdest machine:
===[ The Winner:
This award goes to Ian Beer, Ben Hawkes, and Samuel Groß for decyphering and illuminating
weird machines in the wild, including the most recent ones such as
OffensiveCon'24, "Blasting Past Webp" by Ian Beer and the classic
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html
It is clear that there is a growing gap between private capabilities and public ones.
Given that private entities do not share their mindset, learnings, or scientific structure
of their thinking, reversing and re-discovering these things are tremendously needed.
---[ Runner-up:
"EPF: Evil Packet Filter", Di Jin, Vaggelis Atlidakis, and Vasileios P. Kemerlis
Paper: https://www.usenix.org/system/files/atc23-jin.pdf, USENIX Annual Technical Conference (ATC) 2023
Tools: https://gitlab.com/brown-ssl/epf
Domain-specific virtual machines are a marvelous pattern for managing
complexity. DSL-focused designs that use virtual machines make it possible to change
running production systems at datacenter scales where an equivalent change in C would
be unthinkable. These designs are also arguably the most proof-friendly, with clearer
small-step semantics and properties than most alternatives.
This work reminds us that, even so, these designs are input-driven, capable machines
that can get very weird indeed. Informal clarity was great to get this pattern going,
but will not be enough, especially as more and more infrastructure is based on them.