{Soft,Firm}ware Security 2025-07-06T00:00:00+00:00 https://tiemoko.com/atom.xml 2025-07-06T00:00:00+00:00 2025-07-06T00:00:00+00:00 &copy; 2020-2025 Tiemoko Ballo Tiemoko Ballo https://tiemoko.com/blog/safer-crypto/ <hr /> <!--- * Title and divide on same line * Box border for manually-designated lists ---> <style> .title-divider { display: flex; flex-wrap: nowrap; align-items: center; } .title { flex: 1; flex-grow: 0.001; flex-shrink: 0.001; flex-basis: auto; white-space: normal; text-align: left; padding-right: 0.5rem; } .divider { flex: 1; flex-grow: 1; flex-shrink: 1; flex-basis: 0; height: 2px; background-color: #9a9a9a; margin-top: 0.75rem; } ul.boxed { border: 2px solid #9a9a9a; margin-top: 1rem; padding-bottom: 1rem; padding-top: 1rem; padding-left: 2rem; padding-right: 2rem; } </style> <!--- * Side-by-side diagrams ---> <style> .diagram-row { display: flex; justify-content: space-evenly; align-items: center; } .diagram-col { flex: 50%; max-width: 35%; padding-top: 1%; padding-bottom: 4%; } .diagram-col2 { flex: 50%; max-width: 40%; padding-top: 1%; padding-bottom: 4%; } .diagram-solo { flex: 100%; max-width: 75%; padding-top: 1%; padding-bottom: 4%; } </style> <p>Digital systems our society relies on all have some notion of <strong>trust</strong>. A communicating party can identify, with confidence, <em>who</em> they are "talking" to (authentication). And they can rest assured that their "conversation" is <em>private</em> (confidentiality). Even non-networked systems will validate that code they flash or execute hasn't been <em>modified</em> or <em>corrupted</em> (integrity).</p> <p>Cryptographic libraries are the technical mechanism underpinning properties like authentication, confidentiality, and integrity. These imperfect software components are the foundation on which societal trust is built and maintained. Thus exploitable flaws in crypto libs tend to have severe and widespread impact - e.g. <a rel="noopener" target="_blank" href="https://dl.acm.org/doi/pdf/10.1145/2663716.2663755">[Durumeric, 2014]</a>.</p> <p>Now this two-part post series isn't about applied cryptography in the proper academic sense, we won't explain cryptographic primitives or protocol design from the ground up. Let's assume those more formal concepts live in an <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Ivory_tower">ivory tower</a>. We're medieval peasants fighting in mud that is long-surviving production software - shipping, patching, refactoring.</p> <p>These posts are concerned with brutal realities of deploying [theoretically] sound designs - we aim to reduce certain risks inherent to real-world software. It's one interpretation of what <strong>platform security engineering</strong> entails when shipping trust at scale.</p> <blockquote> <p><em><strong>How are we defining "platform security engineering"?</strong></em></p> <p>Building libraries, frameworks, and tools that allow feature teams to ship both securely and quickly. Essentially providing a "solid security foundation" for high-velocity software. In terms of code-level consistency.</p> </blockquote> <p>We'll use Rust, an increasingly popular systems programming language that <a rel="noopener" target="_blank" href="https://tiemoko.com/blog/blue-team-rust/">guarantees memory safety</a> and tends to encourage functional correctness in limited yet substantial ways. Prior Rust experience isn't required, but will help <em>maximize</em> understanding (and enjoyment?). Concepts we cover are language-agnostic: they likely apply to your problem domain and tech stack of choice.</p> <div class="title-divider"> <div class="title"><h2>So what's the agenda for this two-part series?</h2></div> <div class="divider"></div> </div> <p><strong><a rel="noopener" target="_blank" href="https://tiemoko.com/blog/safer-crypto/">Part 1</a></strong> (this post) focuses on <em>code</em> (full, runnable <a rel="noopener" target="_blank" href="https://github.com/tnballo/high-assurance-rust/blob/main/code_snippets/chp14/tactical_trust">source here</a>). Our proof-of-concept programs aim to raise the bar for "shift left" automation, even if modestly (give the attacker an inch, they'll take a mile). We'll sample solutions to two cryptographic platform security problems at different levels of the stack:</p> <ul> <li> <p>🔐 <span class="title-sub"><b>API<span class="title-separator">:</span></b></span> Can we systematically prevent nonce reuse vulnerabilities in an arbitrarily-large codebase?</p> </li> <li> <p>🔗 <span class="title-sub"><b>Supply-chain<span class="title-separator">:</span></b></span> How should CI enforce policies specific to cryptographic dependencies?</p> </li> </ul> <p><strong><a rel="noopener" target="_blank" href="https://tiemoko.com/blog/%3Cplaceholder%3E/">Part 2</a></strong> will focus on <em>concepts</em> but still include plenty of code. The emphasis is higher-level exploration of a {problem,solution} space. We'll narrow scope to the problem of <em>information disclosure</em>, deep-diving vulnerabilities and state-of-the-art mitigations through the lens of two general threat models:</p> <ul> <li> <p>📡 <span class="title-sub"><b>Man-in-the-Middle (MITM)<span class="title-separator">:</span></b></span> Attacker intercepts network communications between two or more endpoints.</p> </li> <li> <p>💻 <span class="title-sub"><b>Man-at-the-End (MATE)<span class="title-separator">:</span></b></span> Attacker directly compromises one or more communication endpoints.</p> </li> </ul> <blockquote> <p><em><strong>What if I'm interested less in software engineering, more in cryptographic design?</strong></em></p> <p><a rel="noopener" target="_blank" href="https://futurama.fandom.com/wiki/Good_news,_everyone!">Good news, everyone!</a> Although we're focused on code-level tactics, there's several quality, strategy-focused resources to meet you wherever you're currently at and help you construct correct designs. Here's a sample:</p> <ul> <li>Crypto novice but an experienced developer? → <a rel="noopener" target="_blank" href="https://amzn.to/43ov045">"Real-world Cryptography" by Dave Wong</a> <br><br/></li> <li>Work in applied cryptography professionally? → <a rel="noopener" target="_blank" href="https://soatok.blog/category/cryptography/">Soatok's Cryptography Blog</a> <br><br/></li> <li>At the cutting-edge of near-future cryptography? → <a rel="noopener" target="_blank" href="https://rwc.iacr.org/">Real World Crypto Symposium</a></li> </ul> </blockquote> <div class="title-divider"> <div class="title"><h2>&#x1F510; <span class="title-sub">API</span><span class="title-separator">:</span> Prevent Nonce Reuse with Stronger Types</h2></div> <div class="divider"></div> </div> <p>"Nonce" is a portmanteau of "<span style="text-decoration: underline;">n</span>umber used only <span style="text-decoration: underline;">once</span>". As the name implies: accidentally using the same nonce multiple times, aka <em>nonce reuse</em>, is a devastating footgun for many widely-used cryptographic algorithms. Common operations rely on a random nonce as input in order to uphold critical security properties:</p> <ul> <li> <p><strong>Encryption</strong> - Unique nonces are often called "Initialization Vectors" (IVs). They prevent <em>plaintext and/or key recovery</em> as well as <em>replay attacks</em> (malicious repetition of previous communications).</p> <ul> <li>WPA2 was the de facto standard for encryption on Wi-Fi networks from 2006 to 2020. Toward the end of that lifespan, researchers demonstrated a practical attack against all implementations <a rel="noopener" target="_blank" href="https://papers.mathyvanhoef.com/ccs2017.pdf">[Vanhoef, 2017]</a>. By abusing re-transmission logic in the 4-way handshake between a Wi-Fi endpoint and a client joining the network, an attacker could force <em>reset/reuse</em> of the nonce/IV for all protocol-supported stream ciphers (e.g. "keystream reuse"). That means an attacker can decrypt, replay, and [in some cases] forge network packets. Full compromise of the transport layer (e.g. TCP but not HTTPS).</li> </ul> </li> <li> <p><strong>Signing</strong> - Unique nonces prevent <em>signature forging</em> (generating a passing signature for attacker-created data) and <em>signature duplication</em> (replay of previously-signed data).</p> <ul> <li>The Sony PlayStation 3 was poised to become the most secure game console ever made, with no true jailbreak 4 years into production. The PS3 used ECDSA to create a chain-of-trust from early boot to userspace app launch - cryptographically enforcing software license checks. ECDSA signing takes as input a nonce and a hash of data to sign. Hackers discovered that Sony's implementation used a hardcoded nonce <a rel="noopener" target="_blank" href="https://www.youtube.com/watch?v=DUGGJpn2_zY">[FailOverflow, 2010]</a>. This flaw enabled trivial re-computation of the ECDSA <em>private</em> signing key and therefore attacker ability to execute arbitrary unlicensed software.</li> </ul> </li> </ul> <br> <body> <div class="diagram-row"> <div class="diagram-solo"> <img src="..&#x2F;..&#x2F;images&#x2F;tt_nonce_reuse.svg" alt="Nonce reuse in context of encryption"> <br> <figcaption><i><center><b>Fig. 1:</b> Nonce reuse: a single nonce used for multiple encryption operations (red input, step 3+).</center></i></figcaption> </div> </div> </body> <p>So then: how do we prove that, in some arbitrarily-large codebase, all nonces are both random and single-use? By encoding safety invariants into the language's <em>type system</em>. We can create APIs that are nearly impossible to misuse, and we get automatic static verification of that correctness just by compiling a program which uses exclusively the safe APIs!</p> <p>Bold claim, yet relatively straight-forward implementation:</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span>use </span><span style="color:#cccccc;">aead::{ </span><span style="color:#cccccc;"> Aead, AeadCore, Nonce, Payload, </span><span style="color:#cccccc;"> rand_core::{CryptoRng, RngCore}, </span><span style="color:#cccccc;">}; </span><span>use </span><span style="color:#cccccc;">core::error::Error; </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Can be used in arbitrarily many decryption operations. </span><span style="background-color:#171717;color:#616161;">/// Its counterpart, [`EncryptionNonce`], can only be used for one encryption operation. </span><span style="color:#80d500;">pub type </span><span style="color:#cccccc;">DecryptionNonce</span><span>&lt;</span><span style="color:#cccccc;">A</span><span>&gt; = </span><span style="color:#cccccc;">Nonce&lt;A&gt;; </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// A safer nonce type for AEAD. See trait [`NonceSafeAead`]. </span><span style="background-color:#171717;color:#616161;">// </span><span style="background-color:#171717;color:#616161;">// SECURITY: Intentionally opaque and unique. Do not derive/implement any of: </span><span style="background-color:#171717;color:#616161;">// `Default`, `Copy`, `Clone`, `Ord`, `Eq`, `Debug`, etc. </span><span style="color:#80d500;">pub struct </span><span style="color:#cccccc;">EncryptionNonce&lt;A: AeadCore&gt;(Nonce&lt;A&gt;); </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">impl</span><span style="color:#cccccc;">&lt;A: AeadCore&gt; EncryptionNonce&lt;A&gt; { </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Generate a new random nonce for AEAD-specific encryption. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">pub fn </span><span>generate_nonce</span><span style="color:#cccccc;">(</span><span style="font-style:italic;color:#8aa6c1;">rng</span><span style="color:#cccccc;">: impl CryptoRng + RngCore) -&gt; </span><span style="color:#80d500;">Self </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> EncryptionNonce(</span><span>&lt;</span><span style="color:#cccccc;">A </span><span>as</span><span style="color:#cccccc;"> AeadCore</span><span>&gt;</span><span style="color:#cccccc;">::generate_nonce(rng)) </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Crate-private conversion into [`aead::Nonce`]. </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// SECURITY: Do not make `pub`, risks reuse with `aead::Aead` APIs. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">fn </span><span>less_safe_to_raw_nonce</span><span style="color:#cccccc;">(</span><span style="font-style:italic;color:#8aa6c1;">self</span><span style="color:#cccccc;">) -&gt; Nonce&lt;A&gt; { </span><span style="color:#cccccc;"> self.</span><span style="color:#eddd5a;">0 </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;">} </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Nonce-safe AEAD. Guarantees the following properties: </span><span style="background-color:#171717;color:#616161;">/// </span><span style="background-color:#171717;color:#616161;">/// 1. Nonce is random. </span><span style="background-color:#171717;color:#616161;">/// * Opaque type with rand-only constructor. </span><span style="background-color:#171717;color:#616161;">/// 2. Nonce is used in exactly one encryption operation. </span><span style="background-color:#171717;color:#616161;">/// * Pass-by-value consumption. </span><span style="background-color:#171717;color:#616161;">/// </span><span style="background-color:#171717;color:#616161;">/// See also: [`EncryptionNonce`] and [`DecryptionNonce`]. </span><span style="color:#80d500;">pub trait </span><span style="color:#cccccc;">NonceSafeAead { </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Encrypt plaintext payload with a random, single-use nonce. </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Returns ciphertext bytes and decryption-only nonce. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">fn </span><span>nonce_safe_encrypt</span><span style="color:#cccccc;">&lt;</span><span style="color:#80d500;">&#39;msg</span><span style="color:#cccccc;">, </span><span style="color:#80d500;">&#39;aad</span><span style="color:#cccccc;">&gt;( </span><span style="color:#cccccc;"> </span><span>&amp;</span><span style="font-style:italic;color:#8aa6c1;">self</span><span style="color:#cccccc;">, </span><span style="color:#cccccc;"> </span><span style="font-style:italic;color:#8aa6c1;">enc_nonce</span><span style="color:#cccccc;">: EncryptionNonce&lt;</span><span style="color:#80d500;">Self</span><span style="color:#cccccc;">&gt;, </span><span style="color:#cccccc;"> </span><span style="font-style:italic;color:#8aa6c1;">plaintext</span><span style="color:#cccccc;">: impl </span><span style="color:#8aa6c1;">Into</span><span style="color:#cccccc;">&lt;Payload&lt;</span><span style="color:#80d500;">&#39;msg</span><span style="color:#cccccc;">, </span><span style="color:#80d500;">&#39;aad</span><span style="color:#cccccc;">&gt;&gt;, </span><span style="color:#cccccc;"> ) -&gt; </span><span style="color:#8aa6c1;">Result</span><span style="color:#cccccc;">&lt;(</span><span style="color:#8aa6c1;">Vec</span><span style="color:#cccccc;">&lt;</span><span style="color:#80d500;">u8</span><span style="color:#cccccc;">&gt;, DecryptionNonce&lt;</span><span style="color:#80d500;">Self</span><span style="color:#cccccc;">&gt;), impl Error&gt; </span><span style="color:#cccccc;"> </span><span>where </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">Self</span><span style="color:#cccccc;">: AeadCore + Aead + Sized, </span><span style="color:#cccccc;"> { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> nonce </span><span>=</span><span style="color:#cccccc;"> enc_nonce.</span><span style="color:#8aa6c1;">less_safe_to_raw_nonce</span><span style="color:#cccccc;">(); </span><span style="color:#cccccc;"> self.</span><span style="color:#8aa6c1;">encrypt</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="color:#cccccc;">nonce, plaintext) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">map</span><span style="color:#cccccc;">(|</span><span style="font-style:italic;color:#8aa6c1;">ciphertext</span><span style="color:#cccccc;">| (ciphertext, nonce)) </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Decrypt ciphertext. </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Identical to [`aead::Aead::decrypt`], defined so that [`aead::Aead`] </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// doesn&#39;t have to be brought in-scope when using [`NonceSafeAead`]. </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// SECURITY: ban import of less safe `aead::Aead` trait. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">fn </span><span>decrypt</span><span style="color:#cccccc;">&lt;</span><span style="color:#80d500;">&#39;msg</span><span style="color:#cccccc;">, </span><span style="color:#80d500;">&#39;aad</span><span style="color:#cccccc;">&gt;( </span><span style="color:#cccccc;"> </span><span>&amp;</span><span style="font-style:italic;color:#8aa6c1;">self</span><span style="color:#cccccc;">, </span><span style="color:#cccccc;"> </span><span style="font-style:italic;color:#8aa6c1;">dec_nonce</span><span style="color:#cccccc;">: </span><span>&amp;</span><span style="color:#cccccc;">DecryptionNonce&lt;</span><span style="color:#80d500;">Self</span><span style="color:#cccccc;">&gt;, </span><span style="color:#cccccc;"> </span><span style="font-style:italic;color:#8aa6c1;">ciphertext</span><span style="color:#cccccc;">: impl </span><span style="color:#8aa6c1;">Into</span><span style="color:#cccccc;">&lt;Payload&lt;</span><span style="color:#80d500;">&#39;msg</span><span style="color:#cccccc;">, </span><span style="color:#80d500;">&#39;aad</span><span style="color:#cccccc;">&gt;&gt;, </span><span style="color:#cccccc;"> ) -&gt; </span><span style="color:#8aa6c1;">Result</span><span style="color:#cccccc;">&lt;</span><span style="color:#8aa6c1;">Vec</span><span style="color:#cccccc;">&lt;</span><span style="color:#80d500;">u8</span><span style="color:#cccccc;">&gt;, impl Error&gt; </span><span style="color:#cccccc;"> </span><span>where </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">Self</span><span style="color:#cccccc;">: AeadCore + Aead + Sized, </span><span style="color:#cccccc;"> { </span><span style="color:#cccccc;"> </span><span>&lt;</span><span style="color:#80d500;">Self </span><span>as</span><span style="color:#cccccc;"> Aead</span><span>&gt;</span><span style="color:#cccccc;">::decrypt(self, dec_nonce, ciphertext) </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;">} </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// Use above default impl for below algorithms </span><span style="color:#80d500;">impl </span><span style="color:#cccccc;">NonceSafeAead </span><span>for </span><span style="color:#cccccc;">chacha20poly1305::XChaCha20Poly1305 {} </span><span style="color:#80d500;">impl </span><span style="color:#cccccc;">NonceSafeAead </span><span>for </span><span style="color:#cccccc;">aes_gcm::Aes256Gcm {} </span><span style="color:#80d500;">impl </span><span style="color:#cccccc;">NonceSafeAead </span><span>for </span><span style="color:#cccccc;">aes_siv::Aes256SivAead {} </span></code></pre> <p><a rel="noopener" target="_blank" href="https://docs.rs/aead/0.5.2/aead/trait.Aead.html"><code>Aead</code></a> is a widely-used trait in the Rust cryptography ecosystem. It defines a common interface to the <code>encrypt</code> and <code>decrypt</code> operations of Authenticated Encryption with Associated Data (AEAD) algorithms like AES-256-GCM and XChaCha20Poly1305. This class of algorithms provides both confidentiality and integrity, plus optionally allows binding unencrypted, "associated" metadata (think network headers, UUIDs, or contextual info). Basically, an AEAD should be your preferred all-in-one solution for most day-to-day encryption problems.</p> <p>Now the <a rel="noopener" target="_blank" href="https://docs.rs/aead/0.5.2/aead/trait.Aead.html#tymethod.encrypt"><code>Aead</code> enc/decrypt APIs</a> both take a single nonce type by reference: <code>&amp;Nonce&lt;A: AeadCore&gt;</code>. So a programmer is free to encrypt new data with the same nonce they used for decryption earlier (see Figure 1 above).</p> <ul> <li>Notice how a nonce is generic over the <code>AeadCore</code> trait, allowing <em>compile-time</em> verification of algorithm-specific array sizes - e.g. <code>[u8; 12]</code> (96-bit) for AES-256-GCM, <code>[u8; 24]</code> (192-bit) for XChaCha20Poly1305 - at <em>all</em> call-sites.</li> </ul> <p>The crux of our above reuse solution is this: we use two distinct nonce types, <code>EncryptionNonce&lt;A: AeadCore&gt;</code> for <code>encrypt</code> and <code>DecryptionNonce&lt;A: AeadCore&gt;</code> for <code>decrypt</code>. This bifurcation prevents nonce-reuse vulnerabilities, again at <em>compile-time</em> (before shipping and systematically across the entire codebase), because:</p> <ul> <li> <p><code>EncryptionNonce</code> is guaranteed to be <em>randomly-generated</em> (opaque type with rand-only constructor) and <em>single-use</em> (pass-by-value parameter semantics). The single-use property is especially amenable to Rust's [linear] type system. Its decryption counterpart, alias <code>type DecryptionNonce&lt;A&gt; = Nonce&lt;A&gt;;</code>, continues to work normally.</p> </li> <li> <p><a rel="noopener" target="_blank" href="https://docs.rs/rand_core/0.9.3/rand_core/trait.CryptoRng.html">Marker trait <code>CryptoRng</code></a> in <code>fn generate_nonce(rng: impl CryptoRng + RngCore)</code> is critical. A <em>biased</em> (meaning not uniformly random) nonce can be as disastrous as a reused nonce. In another ECDSA debacle, biased nonces allowed extraction of Bitcoin private keys <a rel="noopener" target="_blank" href="https://eprint.iacr.org/2019/023.pdf">[Breitner, 2019]</a>.</p> </li> </ul> <blockquote> <p><em><strong>What about "nonce misuse-resistant" algorithms? And size limitations?</strong></em></p> <p>Strong typing isn't the only possible solution for nonce-reuse. Defenses can also be implemented in the design of the algorithm itself, see <a rel="noopener" target="_blank" href="https://datatracker.ietf.org/doc/html/rfc8452">AES-GCM-SIV</a>. A "Synthetic Initialization Vector" (SIV) uses inputs, including plaintext, to derive the final IV/nonce - effectively forcing two different plaintexts to use two different nonces.</p> <p>However: if the <em>same message</em> is encrypted with the <em>same nonce</em> <span style="text-decoration: underline;">twice</span> under the <em>same key</em>, an attacker will learn that the two messages are equivalent (but not their contents). That equivalence leak could have serious implications in context of a larger threat model, so preventing reuse with strong typing is still the higher assurance option.</p> <p>But we're not out of the woods yet. AES-256-GCM can only safely encrypt <a href="https://www.imperialviolet.org/2015/05/16/aeads.html">2³² (~4.3 billion) messages</a> under the same key using random nonces - beyond that we risk <em>nonce collision</em> (chance reuse). XChaCha20Poly1305 bumps that safe limit to <a href="https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xchacha-03#section-2.1">2⁸⁰ (practically infinite!)</a> and is faster on devices without hardware support for AES.</p> </blockquote> <p>We can verify that the <code>NonceSafeAead</code> trait enc/decrypts as expected with the below unit test:</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span>use </span><span style="color:#cccccc;">aead::{KeyInit, OsRng}; </span><span>use </span><span style="color:#cccccc;">nonce_typing::{EncryptionNonce, NonceSafeAead}; </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">const </span><span style="color:#66ccff;">PLAINTEXT_MSG</span><span style="color:#cccccc;">: </span><span>&amp;</span><span style="color:#cccccc;">[</span><span style="color:#80d500;">u8</span><span style="color:#cccccc;">; </span><span style="color:#eddd5a;">86</span><span style="color:#cccccc;">] </span><span>= </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">b</span><span style="color:#ffd700;">&quot;Two cryptographers walk into a bar. Nobody else has a clue what they&#39;re talking about.&quot;</span><span style="color:#cccccc;">; </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;">#[test] </span><span style="color:#80d500;">fn </span><span>nonce_safe_xchacha20poly1305</span><span style="color:#cccccc;">() { </span><span style="color:#cccccc;"> </span><span>use </span><span style="color:#cccccc;">chacha20poly1305::XChaCha20Poly1305; </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> key </span><span>= </span><span style="color:#cccccc;">XChaCha20Poly1305::generate_key(</span><span>&amp;</span><span style="color:#80d500;">mut</span><span style="color:#cccccc;"> OsRng); </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> cipher </span><span>= </span><span style="color:#cccccc;">XChaCha20Poly1305::new(</span><span>&amp;</span><span style="color:#cccccc;">key); </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> enc_nonce </span><span>= </span><span style="color:#cccccc;">EncryptionNonce::&lt;XChaCha20Poly1305&gt;::generate_nonce(</span><span>&amp;</span><span style="color:#80d500;">mut</span><span style="color:#cccccc;"> OsRng); </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let </span><span style="color:#cccccc;">(ciphertext, dec_nonce) </span><span>=</span><span style="color:#cccccc;"> cipher </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">nonce_safe_encrypt</span><span style="color:#cccccc;">(enc_nonce, </span><span style="color:#66ccff;">PLAINTEXT_MSG</span><span style="color:#cccccc;">.</span><span style="color:#8aa6c1;">as_ref</span><span style="color:#cccccc;">()) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">unwrap</span><span style="color:#cccccc;">(); </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> plaintext </span><span>=</span><span style="color:#cccccc;"> cipher.</span><span style="color:#8aa6c1;">decrypt</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="color:#cccccc;">dec_nonce, ciphertext.</span><span style="color:#8aa6c1;">as_ref</span><span style="color:#cccccc;">()).</span><span style="color:#8aa6c1;">unwrap</span><span style="color:#cccccc;">(); </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> assert_eq!(</span><span>&amp;</span><span style="color:#cccccc;">plaintext, </span><span style="color:#66ccff;">PLAINTEXT_MSG</span><span style="color:#cccccc;">); </span><span style="color:#cccccc;">} </span></code></pre> <p>But does it actually prevent reuse? You're welcome to try passing the same <code>enc_nonce</code> to two different <code>nonce_safe_encrypt</code> calls - the compiler error should look familiar!</p> <blockquote> <p><em><strong>Where do I start with "formally verified" cryptography?</strong></em></p> <p>Proving that a program satisfies a specific property, for any input, is the goal of <em>formal verification</em>. Rust's type system, which guarantees that data is "shared XOR mutable", is particularly amenable to certain formal techniques - less reasoning about the state of memory is needed. Cryptography is also lower-cost to verify: detailed specifications exist, data structures are statically-allocated, and input size is bounded.</p> <p>Verification techniques vary widely (theorem proving, model checking, abstract interpretation, symbolic execution, etc) and the corresponding tools typically require significant expertise to leverage. But as <del>lazy</del> busy developers, we can readily integrate and benefit from already-formally-verified libraries. Two contenders for native cryptography are:</p> <ol> <li><strong><a rel="noopener" target="_blank" href="https://crates.io/crates/aws-lc-rs"><code>aws-lc-rs</code> (Amazon)</a></strong> - Symbolic execution of source code is used to prove that a program matches a machine-readable specification manually encoded from an algorithm's human-readable specification. <br><br/></li> <li><strong><a rel="noopener" target="_blank" href="https://crates.io/crates/symcrypt"><code>symcrypt</code> (Microsoft)</a></strong> - Source is translated to a model for an interactive (meaning semi-manual) theorem prover. Additionally, a combination of fuzzing and model-based testing is used to detect timing side-channels.</li> </ol> <p>Keep in mind that formal verification is not a panacea: specifications can be incomplete and implementations can deviate from models. The aforementioned WPA2 4-way handshake was formally verified yet still exploitable! Its proof failed to specify when a negotiated key should be installed, implicitly allowing multiple installations and thus nonce reset on next install <a rel="noopener" target="_blank" href="https://papers.mathyvanhoef.com/ccs2017.pdf">[Vanhoef, 2017]</a>.</p> </blockquote> <div class="title-divider"> <div class="title"><h2>&#x1f517; <span class="title-sub">Supply-chain</span><span class="title-separator">:</span> Allowlist Crypto Publishers and Ban Duplicates</h2></div> <div class="divider"></div> </div> <p>Programming languages with official package registries are a joy to use: easily finding and integrating 3rd-party libraries means faster delivery speed and greater focus on your problem/business domain. But all convenience has a cost. Here:</p> <ul> <li> <p><strong>Increased attack surface</strong> - Just one malicious crate, no matter how deep in a massive dependency graph, can compromise the entire <em>application</em>. And typo-squatting attacks indiscriminately victimize a percentage of the entire <em>ecosystem</em>.</p> </li> <li> <p><strong>Statistical weakening of memory-safety</strong> - Dependency count likely has some correlation to amount of <code>unsafe</code> Rust code (<a rel="noopener" target="_blank" href="https://rustfoundation.org/media/unsafe-rust-in-the-wild-notes-on-the-current-state-of-unsafe-rust/">19% of public crates use <code>unsafe</code></a>) and other-language CFFI code, and thus amount of total <em>unsound</em> code (realistically some subset of <code>unsafe</code>). Any unsound code can trigger memory safety errors at runtime, which often go undetected in production.</p> </li> <li> <p><strong>Software bloat</strong> - Transitive dependencies tend to <a rel="noopener" target="_blank" href="https://spectrum.ieee.org/lean-software-development">sprawl in number</a>, causing "simple" apps to explode in objective size and complexity. Larger programs generally mean slower app startup and longer download times. Plus both routine (e.g. API upgrade) and emergency (e.g. vulnerable dependency alert) maintenance burden.</p> </li> </ul> <p>Supply-chain assurance is particularly important for cryptographic dependencies, which likely have an out-sized impact on the security properties of an overall system. Application logic higher up the stack tends to rely on crypto libraries, implicitly or explicitly.</p> <p>Imagine you've been handed a strict mandate: the two requirements below <em>must</em> hold for your <em>entire</em> million-plus line monorepo.</p> <ol> <li> <p><strong>Trusted Publishers</strong> - All direct (e.g. non-transitive) cryptographic dependencies must be sourced from a small allowlist of trusted publishers, initially only the <a rel="noopener" target="_blank" href="https://github.com/rustcrypto"><code>RustCrypto</code> organization</a>.</p> <ul> <li> <p><em><strong>Rationale:</strong> Minimize both <a rel="noopener" target="_blank" href="https://rustsec.org/advisories/">RUSTSEC</a> alert volume and backdoor introduction risk.</em></p> </li> <li> <p><em><strong>Scope:</strong> Direct dependencies only. Publishers we explicitly trust can still select their own dependencies.</em></p> </li> </ul> </li> <li> <p><strong>No Duplicates</strong> - All direct and indirect cryptographic dependencies must have exactly one version in-tree at any time.</p> <ul> <li> <p><em><strong>Rationale:</strong> Minimize both bloat and programmer error (e.g. unclear behavior divergence between API versions).</em></p> </li> <li> <p><em><strong>Scope:</strong> All dependencies. Duplicate bloat is likely avoidable - some crate owner should consider updating to latest.</em></p> </li> </ul> </li> </ol> <br> <body> <div class="diagram-row"> <div class="diagram-col2"> <img src="..&#x2F;..&#x2F;images&#x2F;tt_supplychain_1.svg" alt="Before supply-chain policy enforcement"> <br> <figcaption><i><center><b>Fig. 2:</b> No supply-chain policy. Tolerate organic dependency sprawl.</center></i></figcaption> </div> <div class="diagram-col"> <img src="..&#x2F;..&#x2F;images&#x2F;tt_supplychain_2.svg" alt="After supply-chain policy enforcement"> <br> <figcaption><i><center><b>Fig. 3:</b> Policy enforced: only trusted publisher, no duplicates. Leaner app overall.</center></i></figcaption> </div> </div> </body> <p>How do you enforce this policy (which nicely compliments our previous <code>NonceSafeAead</code> APIs)? Unfortunately these specific requirements can't be encoded with <a rel="noopener" target="_blank" href="https://github.com/EmbarkStudios/cargo-deny"><code>cargo deny</code></a>, a popular and mature dependency graph linter, at the time of this writing (v0.18). We need to roll some custom kit atop <a rel="noopener" target="_blank" href="https://docs.rs/cargo_metadata/0.20.0/cargo_metadata/index.html"><code>cargo_metadata</code></a>!</p> <p>Let's start with <a rel="noopener" target="_blank" href="https://rust-unofficial.github.io/patterns/patterns/creational/builder.html">builder-pattern</a> boilerplate (our public API):</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span>use </span><span style="color:#cccccc;">cargo_metadata::{semver::Version, CargoOpt, Metadata, MetadataCommand, Package}; </span><span>use </span><span style="color:#cccccc;">std::{ </span><span style="color:#cccccc;"> cell::OnceCell, </span><span style="color:#cccccc;"> collections::{BTreeMap, BTreeSet, HashMap}, </span><span style="color:#cccccc;"> fs, </span><span style="color:#cccccc;"> path::{Path, PathBuf}, </span><span style="color:#cccccc;">}; </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// A [`Policy`] violation. </span><span style="background-color:#171717;color:#616161;">/// Note: error variants do expose/re-export error enums from 3rd-party crates. </span><span style="color:#cccccc;">#[derive(Debug, Clone, PartialEq, Eq, PartialOrd, Ord)] </span><span style="color:#cccccc;">#[allow(missing_docs)] </span><span style="color:#80d500;">pub enum </span><span style="color:#cccccc;">PolicyViolationError { </span><span style="color:#cccccc;"> DuplicateCrateVersions(</span><span style="color:#8aa6c1;">Vec</span><span style="color:#cccccc;">&lt;</span><span style="color:#8aa6c1;">String</span><span style="color:#cccccc;">&gt;), </span><span style="color:#cccccc;"> DisallowedCategoryPublisher(</span><span style="color:#8aa6c1;">String</span><span style="color:#cccccc;">, </span><span style="color:#8aa6c1;">String</span><span style="color:#cccccc;">), </span><span style="color:#cccccc;"> MetadataReadError(</span><span style="color:#8aa6c1;">String</span><span style="color:#cccccc;">), </span><span style="color:#cccccc;">} </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// A builder for supply-chain policies. </span><span style="color:#cccccc;">#[derive(Default)] </span><span style="color:#80d500;">pub struct </span><span style="color:#cccccc;">Policy { </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// Path to `Cargo.toml` we&#39;re analyzing </span><span style="color:#cccccc;"> manifest_path: PathBuf, </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// Workaround for `OnceCell::get_or_try_init` being nightly-only in Rust 1.88 </span><span style="color:#cccccc;"> cargo_metadata_result: OnceCell&lt;</span><span style="color:#8aa6c1;">Result</span><span style="color:#cccccc;">&lt;Metadata, PolicyViolationError&gt;&gt;, </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// {category} </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// `String`s lower-cased at construction time </span><span style="color:#cccccc;"> no_dup_cats: </span><span style="color:#8aa6c1;">Option</span><span style="color:#cccccc;">&lt;BTreeSet&lt;</span><span style="color:#8aa6c1;">String</span><span style="color:#cccccc;">&gt;&gt;, </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// category: {publisher} </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// `String`s lower-cased at construction time </span><span style="color:#cccccc;"> cat_pubs: </span><span style="color:#8aa6c1;">Option</span><span style="color:#cccccc;">&lt;BTreeMap&lt;</span><span style="color:#8aa6c1;">String</span><span style="color:#cccccc;">, BTreeSet&lt;</span><span style="color:#8aa6c1;">String</span><span style="color:#cccccc;">&gt;&gt;&gt;, </span><span style="color:#cccccc;">} </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">impl </span><span style="color:#cccccc;">Policy { </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Create a new policy, construct with path to workspace or crate-specific `Cargo.toml`. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">pub fn </span><span>new</span><span style="color:#cccccc;">&lt;P&gt;(</span><span style="font-style:italic;color:#8aa6c1;">manifest_path</span><span style="color:#cccccc;">: P) -&gt; </span><span style="color:#8aa6c1;">Result</span><span style="color:#cccccc;">&lt;Policy, std::io::Error&gt; </span><span style="color:#cccccc;"> </span><span>where </span><span style="color:#cccccc;"> P: </span><span style="color:#8aa6c1;">AsRef</span><span style="color:#cccccc;">&lt;Path&gt;, </span><span style="color:#cccccc;"> { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> manifest_path </span><span>= </span><span style="color:#cccccc;">fs::canonicalize(manifest_path)</span><span>?</span><span style="color:#cccccc;">; </span><span style="color:#cccccc;"> </span><span style="color:#8aa6c1;">Ok</span><span style="color:#cccccc;">(</span><span style="color:#80d500;">Self </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> manifest_path, </span><span style="color:#cccccc;"> </span><span>..</span><span style="color:#8aa6c1;">Default</span><span style="color:#cccccc;">::default() </span><span style="color:#cccccc;"> }) </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Rule 1 (Category-specific Trusted Publishers): </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Ensure that a given category only contains crates from a fixed set of trusted publishers. </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Assumes input iterator format `(category_1, publisher_1)...(category_n, publisher_n)`. </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// More then one publisher per category is supported. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">pub fn </span><span>allowed_category_publishers</span><span style="color:#cccccc;">&lt;I, S&gt;(</span><span style="color:#80d500;">mut </span><span style="font-style:italic;color:#8aa6c1;">self</span><span style="color:#cccccc;">, </span><span style="font-style:italic;color:#8aa6c1;">cat_pubs</span><span style="color:#cccccc;">: I) -&gt; Policy </span><span style="color:#cccccc;"> </span><span>where </span><span style="color:#cccccc;"> I: </span><span style="color:#8aa6c1;">Iterator</span><span style="color:#cccccc;">&lt;Item = (S, S)&gt;, </span><span style="color:#cccccc;"> S: </span><span style="color:#8aa6c1;">Into</span><span style="color:#cccccc;">&lt;</span><span style="color:#8aa6c1;">String</span><span style="color:#cccccc;">&gt;, </span><span style="color:#cccccc;"> { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let mut</span><span style="color:#cccccc;"> cat_pubs </span><span>=</span><span style="color:#cccccc;"> cat_pubs.</span><span style="color:#8aa6c1;">peekable</span><span style="color:#cccccc;">(); </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">if</span><span style="color:#cccccc;"> cat_pubs.</span><span style="color:#8aa6c1;">peek</span><span style="color:#cccccc;">().</span><span style="color:#8aa6c1;">is_some</span><span style="color:#cccccc;">() { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let mut</span><span style="color:#cccccc;"> cat_map </span><span>= </span><span style="color:#cccccc;">BTreeMap::new(); </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">for </span><span style="color:#cccccc;">(c, p) </span><span>in</span><span style="color:#cccccc;"> cat_pubs { </span><span style="color:#cccccc;"> cat_map </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">entry</span><span style="color:#cccccc;">(c.</span><span style="color:#8aa6c1;">into</span><span style="color:#cccccc;">().</span><span style="color:#8aa6c1;">to_ascii_lowercase</span><span style="color:#cccccc;">()) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">or_insert</span><span style="color:#cccccc;">(BTreeSet::new()) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">insert</span><span style="color:#cccccc;">(p.</span><span style="color:#8aa6c1;">into</span><span style="color:#cccccc;">().</span><span style="color:#8aa6c1;">to_ascii_lowercase</span><span style="color:#cccccc;">()); </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> self.cat_pubs </span><span>= </span><span style="color:#8aa6c1;">Some</span><span style="color:#cccccc;">(cat_map); </span><span style="color:#cccccc;"> } </span><span style="color:#80d500;">else </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> self.cat_pubs </span><span>= </span><span style="color:#8aa6c1;">None</span><span style="color:#cccccc;">; </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> self </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// ...OMITTED: Rule 2 (Category-specific No Duplicates)... </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Evaluate a built policy against a given workspace/crate. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">pub fn </span><span>run</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="font-style:italic;color:#8aa6c1;">self</span><span style="color:#cccccc;">) -&gt; </span><span style="color:#8aa6c1;">Result</span><span style="color:#cccccc;">&lt;(), PolicyViolationError&gt; { </span><span style="color:#cccccc;"> self.</span><span style="color:#8aa6c1;">run_allowed_category_publishers</span><span style="color:#cccccc;">()</span><span>?</span><span style="color:#cccccc;">; </span><span style="color:#cccccc;"> self.</span><span style="color:#8aa6c1;">run_no_duplicate_crate_categories</span><span style="color:#cccccc;">()</span><span>?</span><span style="color:#cccccc;">; </span><span style="color:#cccccc;"> </span><span style="color:#8aa6c1;">Ok</span><span style="color:#cccccc;">(()) </span><span style="color:#cccccc;"> } </span></code></pre> <p>To keep the length of this post in check, we'll omit implementation of scaffolding for the 2nd policy requirement (no duplicate cryptographic dependencies). But the logic is mechanically similar to the first requirement and the complete, runnable ≈300 lines of source for both rules is <a rel="noopener" target="_blank" href="https://github.com/tnballo/high-assurance-rust/blob/main/code_snippets/chp14/tactical_trust/supplychain_policy">available here</a>.</p> <p>Notice that the above builder doesn't encode anything specific to <em>cryptographic</em> crates - this interface supports arbitrary categories and publishers. Before we see what usage looks like in practice, lets dig into enforcement logic for whatever trusted publishers the user specified when initializing <code>cat_pubs</code> with a call to <code>allowed_category_publishers</code> (the below are private APIs):</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Collect dependency metadata for the entire workspace with all features enabled. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">fn </span><span>metadata</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="font-style:italic;color:#8aa6c1;">self</span><span style="color:#cccccc;">) -&gt; </span><span style="color:#8aa6c1;">Result</span><span style="color:#cccccc;">&lt;</span><span>&amp;</span><span style="color:#cccccc;">Metadata, PolicyViolationError&gt; { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> meta_result </span><span>= </span><span style="color:#cccccc;">self.cargo_metadata_result.</span><span style="color:#8aa6c1;">get_or_init</span><span style="color:#cccccc;">(|| { </span><span style="color:#cccccc;"> MetadataCommand::new() </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">manifest_path</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="color:#cccccc;">self.manifest_path) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">features</span><span style="color:#cccccc;">(CargoOpt::AllFeatures) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">exec</span><span style="color:#cccccc;">() </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">map_err</span><span style="color:#cccccc;">(|</span><span style="font-style:italic;color:#8aa6c1;">e</span><span style="color:#cccccc;">| PolicyViolationError::MetadataReadError(e.</span><span style="color:#8aa6c1;">to_string</span><span style="color:#cccccc;">())) </span><span style="color:#cccccc;"> }); </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> meta_result.</span><span style="color:#8aa6c1;">as_ref</span><span style="color:#cccccc;">().</span><span style="color:#8aa6c1;">map_err</span><span style="color:#cccccc;">(|</span><span style="font-style:italic;color:#8aa6c1;">e</span><span style="color:#cccccc;">| e.</span><span style="color:#8aa6c1;">to_owned</span><span style="color:#cccccc;">()) </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Get repo&#39;s publisher by parsing its URL. </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// SECURITY: `dep.authors` isn&#39;t reliable - anyone can set any value in their crate&#39;s `Cargo.toml`. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">fn </span><span>get_repo_publisher</span><span style="color:#cccccc;">(</span><span style="font-style:italic;color:#8aa6c1;">dep</span><span style="color:#cccccc;">: </span><span>&amp;</span><span style="color:#cccccc;">Package) -&gt; </span><span style="color:#8aa6c1;">Result</span><span style="color:#cccccc;">&lt;</span><span style="color:#8aa6c1;">String</span><span style="color:#cccccc;">, PolicyViolationError&gt; { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let </span><span style="color:#8aa6c1;">Some</span><span style="color:#cccccc;">(repo_url) </span><span>=</span><span style="color:#cccccc;"> dep </span><span style="color:#cccccc;"> .repository </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">as_ref</span><span style="color:#cccccc;">() </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">and_then</span><span style="color:#cccccc;">(|</span><span style="font-style:italic;color:#8aa6c1;">url</span><span style="color:#cccccc;">| url::Url::parse(url).</span><span style="color:#8aa6c1;">ok</span><span style="color:#cccccc;">()) </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">else </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">return </span><span style="color:#8aa6c1;">Err</span><span style="color:#cccccc;">(PolicyViolationError::MetadataReadError(format!( </span><span style="color:#cccccc;"> </span><span style="color:#ffd700;">&quot;Missing or invalid repo URL for crate &#39;</span><span style="color:#66ccff;">{}</span><span style="color:#ffd700;">&#39;&quot;</span><span style="color:#cccccc;">, </span><span style="color:#cccccc;"> dep.name </span><span style="color:#cccccc;"> ))); </span><span style="color:#cccccc;"> }; </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// If `repo_url` == &quot;https://github.com/RustCrypto/AEADs/tree/master/aes-gcm&quot; </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// Then `repo_publisher` == &quot;RustCrypto&quot; </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let </span><span style="color:#8aa6c1;">Some</span><span style="color:#cccccc;">(repo_publisher) </span><span>=</span><span style="color:#cccccc;"> repo_url.</span><span style="color:#8aa6c1;">path_segments</span><span style="color:#cccccc;">().</span><span style="color:#8aa6c1;">and_then</span><span style="color:#cccccc;">(|</span><span style="color:#80d500;">mut </span><span style="font-style:italic;color:#8aa6c1;">path</span><span style="color:#cccccc;">| path.</span><span style="color:#8aa6c1;">next</span><span style="color:#cccccc;">()) </span><span style="color:#80d500;">else </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">return </span><span style="color:#8aa6c1;">Err</span><span style="color:#cccccc;">(PolicyViolationError::MetadataReadError(format!( </span><span style="color:#cccccc;"> </span><span style="color:#ffd700;">&quot;Missing publisher name for repo URL &#39;</span><span style="color:#66ccff;">{repo_url}</span><span style="color:#ffd700;">&#39;&quot; </span><span style="color:#cccccc;"> ))); </span><span style="color:#cccccc;"> }; </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="color:#8aa6c1;">Ok</span><span style="color:#cccccc;">(repo_publisher.</span><span style="color:#8aa6c1;">to_string</span><span style="color:#cccccc;">()) </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">/// Run category-specific trusted publishers check. </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">fn </span><span>run_allowed_category_publishers</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="font-style:italic;color:#8aa6c1;">self</span><span style="color:#cccccc;">) -&gt; </span><span style="color:#8aa6c1;">Result</span><span style="color:#cccccc;">&lt;(), PolicyViolationError&gt; { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let </span><span style="color:#8aa6c1;">Some</span><span style="color:#cccccc;">(</span><span style="color:#80d500;">ref</span><span style="color:#cccccc;"> cat_pubs) </span><span>= </span><span style="color:#cccccc;">self.cat_pubs </span><span style="color:#80d500;">else </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">return </span><span style="color:#8aa6c1;">Ok</span><span style="color:#cccccc;">(()); </span><span style="color:#cccccc;"> }; </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> metadata </span><span>= </span><span style="color:#cccccc;">self.</span><span style="color:#8aa6c1;">metadata</span><span style="color:#cccccc;">()</span><span>?</span><span style="color:#cccccc;">; </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// ID direct dependencies </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> direct_deps </span><span>=</span><span style="color:#cccccc;"> metadata </span><span style="color:#cccccc;"> .packages </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">iter</span><span style="color:#cccccc;">() </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">filter</span><span style="color:#cccccc;">(|</span><span style="font-style:italic;color:#8aa6c1;">pkg</span><span style="color:#cccccc;">| pkg.manifest_path.</span><span style="color:#8aa6c1;">as_path</span><span style="color:#cccccc;">() </span><span>== </span><span style="color:#cccccc;">self.manifest_path) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">map</span><span style="color:#cccccc;">(|</span><span style="font-style:italic;color:#8aa6c1;">pkg</span><span style="color:#cccccc;">| </span><span>&amp;</span><span style="color:#cccccc;">pkg.dependencies) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">flatten</span><span style="color:#cccccc;">() </span><span style="color:#cccccc;"> .collect::&lt;</span><span style="color:#8aa6c1;">Vec</span><span style="color:#cccccc;">&lt;</span><span>_</span><span style="color:#cccccc;">&gt;&gt;(); </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// Get full crate info for each ID-ed direct dependency </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> direct_dep_crates </span><span>=</span><span style="color:#cccccc;"> metadata </span><span style="color:#cccccc;"> .packages </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">iter</span><span style="color:#cccccc;">() </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">filter</span><span style="color:#cccccc;">(|</span><span style="font-style:italic;color:#8aa6c1;">pkg</span><span style="color:#cccccc;">| direct_deps.</span><span style="color:#8aa6c1;">iter</span><span style="color:#cccccc;">().</span><span style="color:#8aa6c1;">any</span><span style="color:#cccccc;">(|</span><span style="font-style:italic;color:#8aa6c1;">dep</span><span style="color:#cccccc;">| dep.name </span><span>== *</span><span style="color:#cccccc;">pkg.name)); </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// Find disallowed category-specific publishers, if any </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">for</span><span style="color:#cccccc;"> dep_crate </span><span>in</span><span style="color:#cccccc;"> direct_dep_crates { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">for</span><span style="color:#cccccc;"> cat </span><span>in &amp;</span><span style="color:#cccccc;">dep_crate.categories { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">if let </span><span style="color:#8aa6c1;">Some</span><span style="color:#cccccc;">(expected_pubs) </span><span>=</span><span style="color:#cccccc;"> cat_pubs.</span><span style="color:#8aa6c1;">get</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="color:#cccccc;">cat.</span><span style="color:#8aa6c1;">to_ascii_lowercase</span><span style="color:#cccccc;">()) { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> actual_publisher </span><span>= </span><span style="color:#80d500;">Self</span><span style="color:#cccccc;">::get_repo_publisher(dep_crate)</span><span>?</span><span style="color:#cccccc;">.</span><span style="color:#8aa6c1;">to_lowercase</span><span style="color:#cccccc;">(); </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">if </span><span>!</span><span style="color:#cccccc;">expected_pubs.</span><span style="color:#8aa6c1;">contains</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="color:#cccccc;">actual_publisher) { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">return </span><span style="color:#8aa6c1;">Err</span><span style="color:#cccccc;">(PolicyViolationError::DisallowedCategoryPublisher( </span><span style="color:#cccccc;"> cat.</span><span style="color:#8aa6c1;">clone</span><span style="color:#cccccc;">(), </span><span style="color:#cccccc;"> actual_publisher, </span><span style="color:#cccccc;"> )); </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="color:#8aa6c1;">Ok</span><span style="color:#cccccc;">(()) </span><span style="color:#cccccc;"> } </span></code></pre> <ul> <li> <p><code>fn metadata</code> does memoized collection of dependency metadata for the entire workspace, with all features enabled. Even if the user specifies 10 requirements for 10 different crate categories, we'll run collection exactly once (recall <code>Policy</code> field <code>cargo_metadata_result</code> is a <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/beta/std/cell/struct.OnceCell.html"><code>OnceCell</code></a>).</p> </li> <li> <p><code>fn get_repo_publisher</code> parses the owner of a repository from its URL. While this logic will extract the publishing <em>user</em> or <em>organization</em> for both GitHub and GitLab URLs, be warned: we're not claiming any of the code in this supply-chain half of this post is robust enough for production usage!</p> <ul> <li>We can't rely on <a rel="noopener" target="_blank" href="https://docs.rs/cargo_metadata/0.20.0/cargo_metadata/struct.Package.html#structfield.authors">the authors field</a> of <code>cargo_metdata</code>'s <code>Package</code> struct, which could be maliciously set to impersonate a publisher. We instead use [presumably valid] URLs as a source of truth for publisher identification. PKI will be a superior long-term solution, more on this later.</li> </ul> </li> <li> <p><code>fn run_allowed_category_publishers</code> is the bulk of our trusted publishers (requirement 1) logic. We identify direct dependencies of the target project (to which <code>Policy::new</code> takes a <code>Cargo.toml</code> path) and iterate that list to look for any crate which belongs to a user-specified category but isn't sourced from a user-allowed publisher for that category.</p> <ul> <li>Crate category labels are optional, but we could extend the builder to support "allowed publisher for any or missing category" - ensuring unexpected publishers don't slip in. Our policy evaluation logic also doesn't validate user-input category names, a typo will cause checks to pass! Adding validation would be straightforward since <a rel="noopener" target="_blank" href="https://crates.io/categories">categories are fixed</a>.</li> </ul> </li> </ul> <p>So how do we roll out enforcement of our sophisticated policy requirements (category-specific trusted publishers and duplicate elimination)? The heavy-handed option is leveraging <code>build.rs</code> (<a rel="noopener" target="_blank" href="https://doc.rust-lang.org/cargo/reference/build-script-examples.html">Rust build scripts</a>):</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span>use </span><span style="color:#cccccc;">supplychain_policy::Policy; </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">fn </span><span>main</span><span style="color:#cccccc;">() { </span><span style="color:#cccccc;"> println!(</span><span style="color:#ffd700;">&quot;cargo:rerun-if-changed=build.rs&quot;</span><span style="color:#cccccc;">); </span><span style="color:#cccccc;"> println!(</span><span style="color:#ffd700;">&quot;cargo:rerun-if-changed=Cargo.toml&quot;</span><span style="color:#cccccc;">); </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> manifest_dir </span><span>= </span><span style="color:#cccccc;">std::env::var(</span><span style="color:#ffd700;">&quot;CARGO_MANIFEST_DIR&quot;</span><span style="color:#cccccc;">).</span><span style="color:#8aa6c1;">expect</span><span style="color:#cccccc;">(</span><span style="color:#ffd700;">&quot;CARGO_MANIFEST_DIR var not set&quot;</span><span style="color:#cccccc;">); </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> manifest_path </span><span>= </span><span style="color:#cccccc;">std::path::PathBuf::from(manifest_dir).</span><span style="color:#8aa6c1;">join</span><span style="color:#cccccc;">(</span><span style="color:#ffd700;">&quot;Cargo.toml&quot;</span><span style="color:#cccccc;">); </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> Policy::new(</span><span>&amp;</span><span style="color:#cccccc;">manifest_path) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">expect</span><span style="color:#cccccc;">(</span><span style="color:#ffd700;">&quot;Invalid manifest path&quot;</span><span style="color:#cccccc;">) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">allowed_category_publishers</span><span style="color:#cccccc;">([(</span><span style="color:#ffd700;">&quot;cryptography&quot;</span><span style="color:#cccccc;">, </span><span style="color:#ffd700;">&quot;rustcrypto&quot;</span><span style="color:#cccccc;">)].</span><span style="color:#8aa6c1;">into_iter</span><span style="color:#cccccc;">()) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">no_duplicate_crate_categories</span><span style="color:#cccccc;">([</span><span style="color:#ffd700;">&quot;cryptography&quot;</span><span style="color:#cccccc;">].</span><span style="color:#8aa6c1;">into_iter</span><span style="color:#cccccc;">()) </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">run</span><span style="color:#cccccc;">() </span><span style="color:#cccccc;"> .</span><span style="color:#8aa6c1;">unwrap</span><span style="color:#cccccc;">() </span><span style="color:#cccccc;">} </span></code></pre> <p>Now failing builds for supply-chain policy violations probably isn't the best way to make friends with other development teams, even in a smaller organization, unless there's a strong regulatory and/or business need to do so. Fortunately the above <code>Policy</code> builder can easily be wrapped in a CLI tool and deployed in <em>blocking</em> or <em>non-blocking</em> CI pipelines, on a workspace-specific basis. Non-blocking failures can be centrally tracked and automatically triaged.</p> <p>Our above proof-of-concept didn't accommodate exceptions (e.g. "allow this specific named duplicate, still enforce for remainder of category"), but you could quickly extend it to read individual crate/publisher names from a [version controlled and <code>CODEOWNERS</code> protected] config file. Supporting legitimate exceptions, with documented rationale, is realistic - "perfect is the enemy of good".</p> <blockquote> <p><em><strong>What are my other options for supply-chain security in Rust?</strong></em></p> <p>The landscape of Rust's supply-chain security tooling is, fortunately, evolving. Sample projects to be aware of:</p> <ul> <li><strong>Signature-based vulnerability alerting:</strong> <a rel="noopener" target="_blank" href="https://github.com/rustsec/rustsec/blob/main/cargo-audit/README.md"><code>cargo audit</code>, a free tool</a> to scan your dependency tree for <a rel="noopener" target="_blank" href="https://rustsec.org/advisories/">known-vulnerable</a> crates, is a must-have for production CI. Although a lack of "reachability analysis" (call-graph traversal to determine if your code directly or indirectly calls a vulnerable function) does mean false positives. <br><br/></li> <li><strong>Heuristic-based malware detection:</strong> The Linux Foundation has <a rel="noopener" target="_blank" href="https://alpha-omega.dev/blog/crustabilities-capabilities-rust-and-capslock/">funded development</a> of a Rust counterpart to Go's <a rel="noopener" target="_blank" href="https://github.com/google/capslock"><code>capslock</code> tool</a>. Among other usecases, <code>capslock</code> enumerates <a rel="noopener" target="_blank" href="https://github.com/google/capslock/blob/main/docs/capabilities.md#capabilities"><em>capabilities</em></a> (file I/O, network connectivity, command execution, etc) for a given dependency and alerts if they suddenly change in a new version. <br><br/></li> <li><strong>Trusted publishers:</strong> Future <a rel="noopener" target="_blank" href="https://rustfoundation.org/media/improving-supply-chain-security-for-rust-through-artifact-signing/">PKI initiatives</a> may allow cryptographic identification of publishers, a big improvement over our above URL parsing. A <a rel="noopener" target="_blank" href="https://rust-lang.github.io/rfcs/3691-trusted-publishing-cratesio.html">related RFC</a> outlines support for publishing crates from trusted infrastructure, following the <a rel="noopener" target="_blank" href="https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/">footsteps of PyPI</a>. Note PKI also means better response capability, although a real-world attack may have already succeeded by the time a build machine pulls a Certificate Revocation List (CRL).</li> </ul> <p>While Rust's intentionally minimal <code>std</code> library is boon for embedded development, it does encourage over-reliance on 3rd-party crates for routine tasks. For contrast: Go's standard library offers <a rel="noopener" target="_blank" href="https://go.dev/doc/security/fips140">FIPS 140-3 compliant cryptography</a> with the flip of a build flag and <a rel="noopener" target="_blank" href="https://go.dev/blog/chacha8rand">backported a secure RNG</a> to existing programs with only a Go toolchain bump!</p> </blockquote> <div class="title-divider"> <div class="title"><h2><span class="title-sub">Takeaway</span></h2></div> <div class="divider"></div> </div> <p>"Trust is earned in drops and lost in buckets". That's probably a maxim, but it feels especially true in the context of commercial software - a global competition in which any winner, perhaps outside of a few monopolists, can be dethroned at any time.</p> <p>Now the technical mechanism for trust is cryptography. Most useful cryptography is implemented and executing, whether on a tiny microcontroller or a beefy server, in the form of code. And code is notoriously difficult to get right, especially when you're shipping a lot of it.</p> <p>Software quality is as challenging to replicate reliably as it is to measure actionably, if not more so. Our best hope is automating repeatability. When the quality criteria is security, automation is one goal of a platform security engineering function. Which needs to keep pace with the broader engineering organization at minimum, and ideally should accelerate all feature teams.</p> <p>This first post explored bite-sized solutions to platform cryptography problems at the API (nonce reuse) and supply-chain (dependency policy) levels. The intent is automating guardrails for <em>human</em> error, but nowadays <em>LLM</em> auto-complete increases vulnerability rate - per both <a rel="noopener" target="_blank" href="https://arxiv.org/pdf/2211.03622">[Perry, 2023]</a> and <a rel="noopener" target="_blank" href="https://dl.acm.org/doi/pdf/10.1145/3610721">[Pearce, 2025]</a>. The good news is that the above techniques should mitigate risks from both sources. Compile-time checks don't care how the code was generated.</p> <p>Our second and final post will have a narrower but deeper scope. We'll explore a classic topic in trust: <em>information disclosure</em> vulnerabilities. Part 2 (release date TBD) grapples with technical concepts at greater length and on the cutting edge. You're going to want a coffee for this one.</p> <p>But it'll still be good fun. Trust me.</p> <hr /> <blockquote> <p><strong>Read a free technical book!</strong> I'm fulfilling a lifelong dream and writing a book. It's about developing secure and robust systems software. Although a work-in-progress, the book is freely available online (no paywalls or obligations): <a rel="noopener" target="_blank" href="https://highassurance.rs/">https://highassurance.rs/</a></p> </blockquote> 2024-01-15T00:00:00+00:00 2024-01-15T00:00:00+00:00 &copy; 2020-2025 Tiemoko Ballo Tiemoko Ballo https://tiemoko.com/blog/usable-insecurity/ <hr /> <p align="center"> <img src="..&#x2F;..&#x2F;images&#x2F;ac6_invalid_build.jpg" alt="AC6 Edit Lock Bypass Build" style="width:100%"> <figcaption><i><center>An <b>invalid</b> AC6 character build created after edit lock bypass of the official "G6 Red" build (PS5 share code: J7ADPMGH313X).</center></i></figcaption> <br> </p> <p>If everyone could make effective use of security practices and services, we'd all be better off. In terms of society's collective defensive posture. <a rel="noopener" target="_blank" href="https://www.usenix.org/system/files/soups2023-mccall.pdf">"Usable Security"</a> examines human factors solutions toward that goal.</p> <p>But what about the inverse: how might <strong>human factors</strong> enable <strong>system misuse</strong>?</p> <p>We'll examine a light-hearted, real-world example of "usable insecurity": generating an <em>invalid</em> game state in "Armored Core 6", then making <em>remediation</em> more costly and complicated for the developer. Any player can escalate persistence for this harmless (no piracy/cheating/data-theft) bug using only the game's GUI. And the deployed defense has palatable tradeoffs.</p> <p>While this post explores product security topics, it is <em>not</em> a <a rel="noopener" target="_blank" href="https://www.exploit-db.com/exploits/45045">deeply-technical exploit writeup</a>. No reverse engineering, asset tampering, runtime instrumentation, social harm, or other potential EULA violations. We're interested in how "power users" can leverage a combo of customization bug and social sharing feature. Without technical skill or any knowledge of software internals.</p> <p>With that air-tight disclaimer out of the way: let's control cosmetic state in a 3rd-person mech action game. Words I never anticipated typing on this blog - and you probably didn't anticipate reading today.</p> <blockquote> <p><em><strong>What's the broader context here, for people that don't play video games?</strong></em></p> <p><em>Armored Core 6: Fires of Rubicon (AC6)</em> is a AAA game by FromSoftware, a critically-acclaimed studio. It marks both the revival and first commercial mega-success of a Japanese mecha action-simulation game series - which debuted in 1997. AC6 won the coveted title of "Best Action Game" at the 2023 Game Awards (think Oscars, but gaming).</p> <p>At the time of this writing AC6 has sold over 2.8 million copies. The fun bug we're dissecting below affects a multi-million person userbase! A surprising scale in context of an industry-leading product. With potential lessons, for bugs in more consequential systems.</p> </blockquote> <h2 id="understanding-the-user-experience">Understanding the User Experience</h2> <p>AC6's core <a rel="noopener" target="_blank" href="https://www.makeuseof.com/gameplay-loop-gaming/">gameplay loop</a> is centered around micro-optimizing character "builds". Builds are combinations of individual combat robot parts, like legs or guns, that give the player an upper-hand in single-player missions and ranked multi-player matches. Build customization injects a stat-heavy strategy layer into what is otherwise a 3rd-person action game.</p> <p>AC6 includes an absurdly deep cosmetic customization system for builds - a logo editor/creator is bundled-in. So a "build" is a <em>player configuration</em> with 2 highly-tunable components:</p> <ol> <li>Robot parts (e.g. functional configuration)</li> <li>Colors/logos (e.g. cosmetic configuration)</li> </ol> <p>Players modify settings for these components using nested menus and, for parts, statistics dashboards.</p> <p>Unlike part tuning, color/logo customization is purely aesthetic - it grants no competitive advantage in gameplay. It's also free of micro-transaction monetization (<a rel="noopener" target="_blank" href="https://www.businessofapps.com/data/fortnite-statistics/">old-school</a>, pro-consumer design).</p> <h2 id="attack-bypassing-the-edit-lock-to-generate-invalid-configs"><span class="title-sub">Attack</span><span class="title-separator">:</span> Bypassing the Edit Lock to Generate Invalid Configs</h2> <p>AC6 players can choose part + color combos freely, with one major exception: official, developer-created character builds are "edit locked". Modifying any <strong>part</strong> in an official build requires <em>removing</em> the lock - <em>resetting</em> all special <strong>colors</strong> to default. The developers' security goal is:</p> <ul> <li><strong>Bind config options:</strong> Make official color-schemes <em>exclusive</em> to official builds. This is a "good state" for builds.</li> </ul> <p>The attacker's exploit goal and motivation are:</p> <ul> <li><strong>Maximum config control:</strong> Remove official build restrictions. For both greater freedom and otherwise impossible builds. We can think of illegally-generated builds as "bad states".</li> </ul> <p>So every build/configuration (some object serialized to local disk for persistence between player logins) has two good/valid states:</p> <ol> <li><strong>Locked</strong> - Official colors + official part set.</li> <li><strong>Unlocked</strong> - Custom colors + official part set <em>or</em> custom parts.</li> </ol> <p>How are good states maintained when a [potentially nefarious] player drives all settings menus? With "locking" logic - a series of internal checks and UI warning banners - the game's menu system attempts to ensure a build never reaches a bad state:</p> <ol start="3"> <li><strong>Invalid</strong> - Official colors + custom parts.</li> </ol> <p>We can visualize the locked and invalid states. The dotted-line box represents the edit lock's binding, solid gray lines represent color-to-part mappings, and the solid red line (right-hand diagram) is an invalid mapping (lock broken, thus binding broken):</p> <style> .ac6row { display: flex; justify-content: space-evenly; align-items: center; } .ac6col { flex: 50%; max-width: 35%; padding-top: 1%; padding-bottom: 4%; } .ac6col2 { flex: 50%; max-width: 40%; padding-top: 1%; padding-bottom: 4%; } </style> <body> <div class="ac6row"> <div class="ac6col"> <img src="..&#x2F;..&#x2F;images&#x2F;ac6_valid.svg" alt="AC6 good states"> <br> <figcaption><i><center><b>Fig. 1:</b> Good mappings, lock-enforced.</center></i></figcaption> </div> <div class="ac6col"> <img src="..&#x2F;..&#x2F;images&#x2F;ac6_invalid.svg" alt="AC6 good states"> <br> <figcaption><i><center><b>Fig. 2:</b> New bad mapping, lock bypass.</center></i></figcaption> </div> </div> </body> <p>So to create an invalid build, the player needs to bypass the edit lock. Turns out this is trivial! The AC6 community, including <a rel="noopener" target="_blank" href="https://www.reddit.com/r/armoredcore/comments/16czv82/simple_trick_to_remove_an_acs_edit_lock/">Reddit users</a> and <a rel="noopener" target="_blank" href="https://www.youtube.com/watch?v=NcNz-H3Hyqo">YouTube channels</a>, found a simple GUI-only bypass just 2 weeks after the game's August 2023 launch. Steps:</p> <!--- Internal note for image crops: - Pos: 1160, 720 - Size: 1520, 720 ---> <style> .ac6step { display: flex; align-items: center; justify-content: space-between; } .ac6img { max-width: 40%; max-height: 40%; } .ac6text { padding-left: 2%; padding-right: 3%; } </style> <body> <br> <div class="ac6step"> <div class="ac6text"> <br>1. <b>Load an edit-locked official build: </b> <i>AC DESIGN</i> > <i>AC DATA</i> > <i>PRESET</i> > (select official build) > <i>LOAD</i> > <i>YES</i>.<br><br><i>State: <b>locked</b> - parts cannot be edited without losing custom color scheme.</i> </div> <div class="ac6img"> <img src="..&#x2F;..&#x2F;images&#x2F;ac6_step_1.jpg"> </div> </div> <div class="ac6step"> <div class="ac6text"> <br>2. <b>Remove the lock from the <i>PAINT</i> menu: </b> <i>AC DESIGN</i> > <i>PAINT</i> > (note "An edit lock is in place for this data..." warning) > <i>YES</i> (remove lock, notice reset color scheme).<br><br><i>State: [intermediate/transitioning].</i> </div> <div class="ac6img"> <img src="..&#x2F;..&#x2F;images&#x2F;ac6_step_2.jpg"> </div> </div> <div class="ac6step"> <div class="ac6text"> <br>3. <b>Exit the <i>PAINT</i> menu without saving changes: </b> (press platform-specific back button) > <i>Discard Edits and Quit.</i><br><br><i>State: <b>invalid</b> (lock bypassed) - keeps official color scheme, sans logo decals, but parts are now fully editable.</i> </div> <div class="ac6img"> <img src="..&#x2F;..&#x2F;images&#x2F;ac6_step_3.jpg"> </div> </div> <br> </body> <p>That's all it takes. Driving the menus to an unlocked edit state (<em>YES</em> remove lock) and undoing the corresponding color reset (<em>PAINT</em> &gt; <em>Discard Edits and Quit</em>). Binding broken.</p> <p>Note invalid builds enable otherwise impossible creations. For example, <a rel="noopener" target="_blank" href="https://youtu.be/NcNz-H3Hyqo?t=18">high headlight brightness values</a> can be inherited from the bypassed official build - these values would be fixed and much lower otherwise.</p> <p>Now that we understand the bug, let's look at a way to persist its results.</p> <h2 id="battle-patch-delivery-vs-social-replication"><span class="title-sub">Battle</span><span class="title-separator">:</span> Patch Delivery vs. Social Replication</h2> <p>For a user, builds are labor-intensive outputs. The player could've spent hours tweaking parameters for a single build file. So the data is always saved locally.</p> <p>Here's the kicker: we can replicate build data across other player's geographically-distributed systems. Fully <strong>opt-in</strong> for all parties. AC6 has "share codes":</p> <ul> <li> <p>Player A uploads their build and gets a pseudo-random identifier (the "code").</p> </li> <li> <p>Player A transmits the code using some out-of-band channel (e.g. private DM, public forum post, etc).</p> </li> <li> <p>Player B redeems the code (non-exclusive) to download a local copy of player A's build data.</p> </li> </ul> <p>Built-in social sharing that works exactly like you'd expect - solid value add. You might've already guessed where this is going: sharing invalid builds. Not a terribly novel idea. Yet there are at least two big-picture scenarios worth <a rel="noopener" target="_blank" href="https://csrc.nist.gov/glossary/term/tabletop_exercise">table-topping</a> out.</p> <br> <body> <div class="ac6row"> <div class="ac6col2"> <img src="..&#x2F;..&#x2F;images&#x2F;ac6_data_rollback.svg" alt="Data Rollback (Anti-patch)" style="width:100%"> <br> <figcaption><i><center><b>Fig. 3:</b> Sharing an invalid build with a fully-patched client.</center></i></figcaption> </div> <div class="ac6col2"> <img src="..&#x2F;..&#x2F;images&#x2F;ac6_dist_persist.svg" alt="Distributed Persistence (Anti-wipe)" style="width:100%"> <br> <figcaption><i><center><b>Fig. 4:</b> Persisting invalid builds across the player base.</center></i></figcaption> </div> </div> </body> <p>But first: <strong>opt-in</strong> is worth re-iterating - this design makes invalid builds user-controlled data. The bug is not <a rel="noopener" target="_blank" href="https://www.vice.com/en/article/the-myspace-worm-that-changed-the-internet-forever">"worm-able"</a> to unsuspecting clients, copying invalid builds is a player choice. That's best case. Explicit user authorization is a critical last line of defense, for many <a rel="noopener" target="_blank" href="https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/how-it-works#uac-process-and-interactions">software systems</a>.</p> <!-- Think security prompts, privacy toggles, protection disables, etc. Giving smart humans with a vested interest the choice of optional, lazy-evaluated risk. [meta] You're reading my site's source aren't you? Hi from one hacker to another :) Here's a flag{e4st3r_e66}: - Full-size opening invalid build screenshot (J7ADPMGH313X): https://tiemoko.com/images/ac6_invalid_build_large.jpg - Full-size PoC screenshot (G1DKZZV8GEUC): https://tiemoko.com/images/ac6_preorder_export_poc_large.jpg --> <p>Now when player B redeems a code the shared build is <em>re-locked</em> on download. Player B must locally repeat the bypass to gain full edit control. So social sharing doesn't propagate the bypassed state itself, only the resulting invalid build. The existence of lock-on-download logic implies the edit lock is intended to bind configuration for <em>shared</em> builds - not just <em>official</em> builds.</p> <p>We omitted this nuance earlier, for simplicity, but the ramification is important: the edit lock has the same failure mode for <em>two</em> distinct usecases, it fails to protect <em>both</em> <strong>developer-generated</strong> and <strong>user-generated</strong> content.</p> <p>With those caveats out of the way, we'll examine our two persistence scenarios.</p> <h3 id="1-data-rollback-anti-patch"><em><span class="title-sub">1</span><span class="title-separator">.</span> Data Rollback <span class="title-separator">(Anti-patch)</span></em></h3> <p>As of patch version 1.05, the edit lock bypass hasn't been fixed. FromSoftware may well intentionally leave it in, we can't be certain. Maybe it could even be made an official achievement for good sport.</p> <p>But suppose the developer opts to patch. The reasonable fix is to stop creation of <em>new</em> invalid/bypassed builds without deleting <em>existing</em> save data. So players don't experience sudden remote wipe of their meticulous customization work (e.g. data loss).</p> <p>Then post-patch users (e.g. those running the latest release) can't create an invalid build locally. But they <em>can</em> download one created previously, via share code. That means fully-patched clients can <em>roll back</em> their game data to a "bad" state (see figure 3 above), which should have only been reachable in an unpatched client. And that bad state won't be fixed by future patches.</p> <p>One way to prevent this scenario, without data loss, is selective blocking of share codes: disallow any which IDs an invalid build. For strong enforcement, blocking needs to be done <em>server-side</em> and on <em>upload</em>.</p> <p>Let's imagine, for the sake of experiment, that FromSoftware chooses the nuclear option - server-side block all relevant social share codes <em>and</em> remote wipe all client-local invalid builds (forced user data loss). Single goal: no survivors.</p> <h3 id="2-distributed-persistence-anti-wipe"><em><span class="title-sub">2</span><span class="title-separator">.</span> Distributed Persistence <span class="title-separator">(Anti-wipe)</span></em></h3> <p>When a player transmits a share code, they can do so on a broadcast channel - post it publicly for anyone to download. Broadcast sharing means attack asymmetry: a single share ID has the potential to replicate build data across <code>N</code> clients (figure 4).</p> <blockquote> <p><strong>Proof-of-Concept:</strong> G1DKZZV8GEUC is a PS5 share code for the "G13 Raven" official build (sans decals) - created using the above edit lock bypass. This build was an exclusive pre-order bonus, and can't be acquired otherwise. You can re-bypass and save a local copy for offline use :)</p> </blockquote> <p>In the general case, as <code>N</code> gets higher the probability of a complete (all affected clients) remote delete gets lower. Maybe there's some legal/process/risk hurdle to data deletion. Maybe client connectivity is intermittent. Maybe offline, whole-system backups have already been made (think enterprise environment). Or maybe users intentionally keep systems offline to retain bad state (a <a rel="noopener" target="_blank" href="https://youtu.be/5Cq3K9lBli0?feature=shared&amp;t=330">common practice</a> for game consoles with known-vulnerable firmware, for <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Homebrew_(video_games)">homebrew</a> XOR piracy reasons). In every scenario, it's challenging to <em>strongly guarantee</em> deletion of <code>N</code> copies across <code>N</code> nodes as <code>N</code> gets huge (maybe multi-million).</p> <p>Now AC6 is a high-margin product, both in unit sales (e.g. physical/digital game purchases) and platform subscription revenue (e.g. PS5 multiplayer SaaS). So it's unsurprising that the game shipped with anti-abuse countermeasures on day one.</p> <h2 id="defense-forced-remote-wipe-on-connect"><span class="title-sub">Defense</span><span class="title-separator">:</span> Forced Remote Wipe on Connect</h2> <p>While poking at edge cases for this post, I came across build-error-detection logic and a <a href="../../images/ac6_error_detection.jpg">corresponding prompt UI</a> for forced remote wipe (no ability to opt-out if client is network-connected). To the best of my knowledge, this "kill switch" is only used for data either willingly deleted by the owner (e.g. original removed) or forcibly taken down by the developer (e.g. an inappropriate custom logo is reported, a content moderation team takes action).</p> <p>This means FromSoftware already has production-tested capability for remote wipe <em>after</em> data hits disk, but not selective blocking <em>beforehand</em>. Although simple and likely effective in practice, remote wipe has at least two significant drawbacks:</p> <ul> <li> <p><strong>Fallible</strong> - The client stores an invalid config locally and must connect to game servers to remediate. Locally-generated invalid builds are fully functional as long as the game is played offline. So the theoretical worst case exposure time is <em>indefinitely</em> long.</p> <ul> <li>Especially on PC, where native code and network traffic can be instrumented by technical users. Software-only, client-side security controls are limited to "best effort" guarantees. For some applications, "best effort" isn't "good enough".</li> </ul> </li> <li> <p><strong>Destructive</strong> - Remote build wipe is forced data loss. For any user who redeemed a share code, not just the user who knowingly bypassed the lock. The cost of defense includes widespread "collateral damage".</p> <ul> <li>For many software services, data loss risks a permanent reputation hit and significant customer turnover.</li> </ul> </li> </ul> <p>But let's not miss the forest for the trees. The FromSoft team shipped a smash hit, cross-platform game with few stability issues or technical glitches. They've implemented a capability for emergency removal of objectionable content and have thus far managed to prevent <a rel="noopener" target="_blank" href="https://gamerant.com/call-of-duty-modern-warfare-3-cheating-increase-complaints/">multiplayer cheating</a>. While the security industry all-too-often learns from embarrassing public failures, this post examines finer details in what is an unequivocal success - by any measure.</p> <blockquote> <p><em><strong>Any now-harmless, historical examples of usable insecurity in games?</strong></em></p> <p>YouTube channel "Modern Vintage Gamer" <a rel="noopener" target="_blank" href="https://www.youtube.com/watch?v=uRB7iUCX4KQ">announced a 23 year-old zero-day</a> for bypassing Sony PS1 game-disk DRM. A movie-license game, released October 2000, included code to "hot swap" game discs. That's a common feature for multi-disk games of the CD era. To continue game story/progression while loading new assets from additional storage media.</p> <p>Except this big-budget game had only 1 disc when it shipped.</p> <p>The player enters a disk-swap debug mode if a special "cheat code" is manually input (think "backdoor"). Enable this mode, swap the current/official disk for any home-made copy of game B, and you've now launched game B. No signature validation, no region lock. Complete, usable <a rel="noopener" target="_blank" href="https://www.youtube.com/playlist?list=PLUbw0IXAmW2rMk5g19MrqcyebecSrrSeJ">DRM unlock</a> for clients that won't be patched.</p> </blockquote> <h2 id="takeaway"><span class="title-sub">Takeaway</span></h2> <p>We explored a low-stakes but realistic "usable insecurity" case study. No cheating or piracy involved. Fully opt-in persistence. We saw how any non-technical user could create and preserve an invalid state, via interaction of two factors:</p> <ol> <li> <p><strong>Bug</strong> (edit lock bypass) - GUI-only flow to create a local, invalid configuration.</p> </li> <li> <p><strong>Feature</strong> (social sharing) - Official mechanism to sync configurations across clients.</p> </li> </ol> <p>Nothing but respect for FromSoftware - have been an AC fan since 3 back on the PS2. This time it was all fun and [literally] games! Anything worth extrapolating?</p> <p>Complex systems are difficult to reason about. Business logic often has exponential branching paths, e.g. "state explosion". So all real-world products ship with some non-zero number of bugs.</p> <p>Most systems can be patched after bugs are discovered. But patching is non-trivial for complex systems and/or large populations. And when the technical barrier to system subversion is low, any client can become uncooperative. Sometimes coordinated entities can systematically degrade patching capability by increasing its cost. Leveraging unexpected <strong>bug-bug</strong>, <strong>bug-feature</strong>, or even <strong>feature-feature</strong> composition.</p> <p>So it's best to fix bugs - especially the subset that are exploitable vulnerabilities - before shipping. Instead of attempting to put out the fires [of Rubicon]. Doubly true for "usable vulnerabilities", those reliable for low-skill attackers. Prevention isn't always possible but tends to minimize tradeoffs when it is.</p> <p>Thus - assuming an architecture/design process already succeeded - we should invest in:</p> <ul> <li> <p><strong>Automated and Manual Testing</strong> - Maybe unit tests asserting on <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel">view-models</a> returned from functions could have caught the AC6 bug. When <a rel="noopener" target="_blank" href="https://tiemoko.com/blog/diff-fuzz/">automated tests</a> are infeasible, both <em>exploratory</em> (e.g. pre-merge code review) and <em>structured</em> (e.g. pre-release QA testing) manual effort is exceptionally valuable. Sure - detecting certain flaws, like memory-safety violations, is best left to tools. But in the general case human smarts can find defects automation won't. At scale, repeatable processes can harness those smarts.</p> </li> <li> <p><strong>Formal Verification</strong> - Limited, but important, classes of problems can be defined out of existence. Maybe a menu design based on <a rel="noopener" target="_blank" href="http://cliffle.com/blog/rust-typestate/">Rust's type-state pattern</a> could enable provably correct lock state. If invalid states could cause damage to property or loss of human life, it's wise to guide implementation with a <a rel="noopener" target="_blank" href="http://lamport.azurewebsites.net/tla/industrial-use.html">formal model of the intended system</a> and/or <a rel="noopener" target="_blank" href="https://github.com/verus-lang/verus">use machine-checked annotations</a> to validate functional correctness of the code itself. Unlike testing, verification can prove the absence of certain bugs (within some bounds, e.g. micro-architectural attacks typically out-of-scope).</p> </li> </ul> <p>Security matters when the next breach might be "game over". Good luck out there.</p> <hr /> <p><em>02-22-2024 update: <a rel="noopener" target="_blank" href="https://en.bandainamcoent.eu/armored-core/news/armored-core-vi-fires-of-rubicon-patch-notes-106">1.06 patch notes</a>, released 02-05-2024, include "Fixed a bug with AC data uploaded to the game server, where if the data was loaded and then deleted from the game server, the loaded data would be reverted to default paint and decals". We previously triggered this bug to capture the <a href="../../images/ac6_error_detection.jpg">"kill switch" UI screenshot</a> linked in discussion of defense. Given this fix, assume the kill switch is only for forced removal. Post text remains unedited, both share codes are still active, the focal bypass still works in 1.06!</em></p> <hr /> <blockquote> <p><strong>Read a free technical book!</strong> I'm fulfilling a lifelong dream and writing a book. It's about developing secure and robust systems software. Although a work-in-progress, the book is freely available online (no paywalls or obligations): <a rel="noopener" target="_blank" href="https://highassurance.rs/">https://highassurance.rs/</a></p> </blockquote> 2022-01-29T00:00:00+00:00 2022-01-29T00:00:00+00:00 &copy; 2020-2025 Tiemoko Ballo Tiemoko Ballo https://tiemoko.com/blog/vintage-tech-books/ <hr /> <p><em>01-31-2022 update: <a rel="noopener" target="_blank" href="https://www.reddit.com/r/programming/comments/sfl0jt/technical_time_travel_on_vintage_programming_books/">Reddit discussion here</a>. "The Mythical Man-Month" by Frederick Brooks (1975) was highly recommended!</em></p> <p><em>03-20-2022 update: <a rel="noopener" target="_blank" href="https://news.ycombinator.com/item?id=30697697">Hacker News discussion here</a>. Interesting perspectives and vintage recommendations.</em></p> <hr /> <p>As technologists, we're constantly gulping from the bleeding-edge firehose: new versions, new standards, new frameworks, new paradigms. This is largely a good thing. Most advances offer a tangible improvement over the status quo. Specialization (e.g. recent <a rel="noopener" target="_blank" href="https://www.cmu.edu/news/stories/archives/2018/may/ai-undergraduate-degee.html">Bachelors Degrees in AI</a>) speeds the advance of promising fields, it's a future of exciting possibility. So long as our eager technology can be <a rel="noopener" target="_blank" href="https://undark.org/2020/10/16/book-review-ai-in-the-wild/">guided by effective policy</a>.</p> <p>What if we turn that lens backward, toward the yesteryear innovations of our shared past? Not in an effort to gain some competitive edge in the present - although the insight of historical context can be piercing - but simply to satisfy intellectual curiosity. To scratch that innocent itch for understanding how things work. Or, given hindsight, why they didn't.</p> <p>To this end, I enjoy collecting rare and vintage programming books. It's not a hobby that leads to party invitations. But it is surprisingly cheap (the demand for used and outdated technical references is small). And mildly satisfying. There's just something quaint about pre-internet computer books, with their dead-tree print editions and crude typesetting. Each offering an alluring nostalgia, somehow palatable even if the era is before your own.</p> <p>This post shares three of my favorites and summarizes the historical backdrop for each. All three have ties to modern-day tech, so I hope you'll find some aspect informative or interesting. Hit the gas until <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/DeLorean_time_machine">88 MPH</a>, we're going back Marty!</p> <h2 id="1-debugging-with-gdb-by-richard-stallman-et-al-1988-present"><span class="title-sub">1</span><span class="title-separator">)</span> <em>Debugging with GDB</em> by Richard Stallman et al. <span class="title-separator">(1988 - Present)</span></h2> <br> <p align="center"> <img src="..&#x2F;..&#x2F;images&#x2F;book_gdb.jpg" alt="Debugging with GDB (1988 - Present)" style="width:100%"> </p> <p>Having done <a rel="noopener" target="_blank" href="https://tiemoko.com/publications/asia_ccs_2021_sok_enabling_security_analyses_of_embedded_systems_via_rehosting.pdf">academic research</a> in dynamic program analysis, I have something of a soft spot for debuggers and emulators. The 1st edition of the long-running "Debugging with GDB" series was copyrighted in 1988. In fitting Free Software Foundation (FSF) fashion, the most current edition is <a rel="noopener" target="_blank" href="https://www.sourceware.org/gdb/current/onlinedocs/gdb.html">freely available</a> online. It's <em>the</em> comprehensive reference for <code>gdb</code> - a userland debugger supporting Unix-like systems.</p> <p><code>gdb</code> is a cornerstone of the incredibly influential <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/GNU_toolchain">GNU toolchain</a>. This toolchain includes, among others, the <code>gcc</code> compiler, the <code>glibc</code> C standard library, and the <code>make</code> build system - software fundamental to both the rise of the Linux kernel and systems programming in general. Because GNU technologies are so ubiquitous on the server-side, almost all of your daily computer use is, in some direct or indirect way, enabled by GNU utilities. This handful of tools annually generates <em>billions</em> of dollars in value.</p> <p><a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Richard_Stallman">Dr. Richard Stallman</a>, the original author of several GNU programs, personally signed this 2010 copy when I met him at a software conference in 2016. I distinctly remember people getting up and walking out halfway through his conference-closing keynote, which espoused the exploitative nature of cloud services. Categorically. Any and all usage of remote machines running code managed by another party. Though no doubt an icon of computing, Stallman could be described as an <a rel="noopener" target="_blank" href="https://www.washingtonpost.com/education/2019/09/17/computer-scientist-richard-stallman-resigns-mit-after-comments-about-epstein-scandal/">abrasive speaker</a>.</p> <p>While Stallman's grandiose vision for collective ownership of all software did not come to pass, it certainly left a mark. Today's open ecosystems are likely a result of the FSF shifting our <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Overton_window">Overton window</a>. And we're all reaping the benefits. Daily.</p> <blockquote> <p><strong>Classic Problems, Modern Solutions</strong></p> <p><a rel="noopener" target="_blank" href="https://www.sourceware.org/gdb/"><code>gdb</code></a>/<a rel="noopener" target="_blank" href="https://rr-project.org/"><code>rr</code></a> is one of the few late 80s developer tools still popular today. With forward and reverse engineers alike, nonetheless. Perhaps it's unsurprising that several recent startups ship debugging and observability products. The Total Addressable Market (TAM) for a timeless need is sizable.</p> <p>Some of these startups include (listed alphabetically, non-exhaustive, and <em>not</em> an endorsement of any products): <a rel="noopener" target="_blank" href="https://logrocket.com/features/">logrocket.com</a>, <a rel="noopener" target="_blank" href="https://www.metawork.com/">metawork.com</a>, <a rel="noopener" target="_blank" href="https://www.replay.io/">replay.io</a>, and <a rel="noopener" target="_blank" href="https://www.tetrane.com/">tetrane.com</a>.</p> </blockquote> <h2 id="2-bios-interface-technical-reference-by-ibm-1987"><span class="title-sub">2</span><span class="title-separator">)</span> <em>BIOS Interface Technical Reference</em> by IBM <span class="title-separator">(1987)</span></h2> <br> <p align="center"> <img src="..&#x2F;..&#x2F;images&#x2F;book_bios.jpg" alt="Personal System/2 and Personal Computer BIOS Interface Technical Reference (1987)" style="width:100%"> </p> <p><a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Clean_room_design">"Clean-room design"</a> was an underhanded way to legally reverse engineer and clone a competitor's product. It works like this: engineer A produces a specification after studying the competing product, a lawyer signs off on the spec not including copyrighted material, and engineer B re-implements the product from the spec A created. A and B have the same employer, but since they're not the same person there's <em>technically</em> no copyright infringement. This technique was used during the fiercely-competitive market rush of early personal computing.</p> <p>Perhaps its most infamous application was the recreation of IBM's Basic Input-Output System (BIOS). IBM's Personal Computer (PC) introduced home computing to an entire generation, ushering in a new era. It catalyzed mainstream adoption of general-purpose computers, which had largely been corporate tools and hobbyist curiosities. By reverse engineering its BIOS, a piece of low-level firmware, competitors could reduce time-to-market for software-compatible clones of IBM's flagship consumer product.</p> <p>That's exactly what successful companies like <a rel="noopener" target="_blank" href="https://www.allaboutcircuits.com/news/how-compaqs-clone-computers-skirted-ibms-patents-and-gave-rise-to-eisa/">Compaq Computer</a> and <a rel="noopener" target="_blank" href="https://books.google.com/books?id=Bwng8NJ5fesC&amp;lpg=PA6&amp;pg=PA56#v=onepage&amp;q&amp;f=false">Phoenix Technologies</a> did. One team obtained IBM technical manuals, likely very similar to <a rel="noopener" target="_blank" href="http://bitsavers.trailing-edge.com/pdf/ibm/pc/ps2/PS2_and_PC_BIOS_Interface_Technical_Reference_Apr87.pdf">the book pictured above</a>, and wrote specifications that described program behavior without including any of the book's code. Another team wrote a BIOS clone compliant with the specs, likely in assembly language, and then ran PC software atop the replica to check that it functioned as intended. Unethical? Probably. Effective? Definitely.</p> <blockquote> <p><strong>Dominance via Interoperability</strong></p> <p>Almost all modern laptops/desktops/servers are direct descendants of the 1981 IBM PC, and use an updated version of its x86 architecture. It's a legacy of enduring monoculture. So why did the PC dominate so convincingly?</p> <p>Perhaps because it was a break from tradition for Big Blue, <a rel="noopener" target="_blank" href="https://adventofcomputing.libsyn.com/episode-51-the-ibm-pc">Sean Haas posits</a>. Whereas the company's mainframe machines used a proprietary tech stack, the PC was open and modular, readily supporting 3rd-party hardware and software. Its design team prioritized both time-to-market and production capacity by intentionally mating mass-produced 8-bit peripherals to their 16-bit CPU (a variant of the venerable Intel 8086). Had different choices been made, maybe Apple's recent <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Apple_M1">ARM SoC</a> wouldn't be so notable an exception to the x86 rule.</p> <p>BIOS may have been sunset in favor of <a rel="noopener" target="_blank" href="https://uefi.org/specifications">UEFI</a>, but the 8086 CPU refuses to die. To this day, your brand new 64-bit x86 PC or console will boot into <a rel="noopener" target="_blank" href="https://wiki.osdev.org/Real_Mode">"real-mode"</a> on startup - ready to execute 16-bit instructions with a whopping 1MB of addressable memory. It's a strange bit of technical debt, an artifact of a 40-year commitment to backward compatibility. And likely to be around for 40 more.</p> </blockquote> <h2 id="3-the-ada-reference-manual-by-honeywell-1983"><span class="title-sub">3</span><span class="title-separator">)</span> <em>The Ada Reference Manual</em> by Honeywell <span class="title-separator">(1983)</span></h2> <br> <p align="center"> <img src="..&#x2F;..&#x2F;images&#x2F;book_ada.jpg" alt="Reference Manual for the Ada Programming Language (1983)" style="width:100%"> </p> <p>In the late 70s, the US Department of Defense (DoD) had a critical problem: their embedded systems projects used <a rel="noopener" target="_blank" href="https://ocw.mit.edu/courses/aeronautics-and-astronautics/16-01-unified-engineering-i-ii-iii-iv-fall-2005-spring-2006/comps-programming/15_robertdewar.pdf">over 450 esoteric programming languages</a>, maintenance was a multi-billion dollar burden. The government's answer? Standardization. Create a new language specially tailored to safety-critical embedded systems and legally mandate its use for applicable projects.</p> <p>In 1978, the DoD put forth the <a rel="noopener" target="_blank" href="https://web.archive.org/web/20200914235620/https://dwheeler.com/steelman/steelman.htm">"Steelman" requirements list</a> and sponsored a competition (not unlike the more contemporary <a rel="noopener" target="_blank" href="https://www.darpa.mil/news-events/2014-03-13">DARPA "Grand Challenges"</a>). Four language design teams entered the fray: red, green, blue, and yellow. The green team won and produced the above <a rel="noopener" target="_blank" href="http://archive.adaic.com/standards/83lrm/html/lrm-TOC.html">language specification</a>, hence the binding color. This one is a commemorative copy with a forward thanking the original Honeywell development team.</p> <p>Their language was named "Ada", after <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Ada_Lovelace">Ada Lovelace</a> - a pioneering programmer who debugged her yet-to-be-built <em>mechanical</em> computer via mail correspondence. The spec's official document number, MIL-STD-1815-A, includes Lovelace's 1815 birthdate.</p> <blockquote> <p><strong>On Modern Ada</strong></p> <p>Today's Ada boasts impressive features rarely seen in other programming languages. Including range types (encoding valid ranges of values at the type system level) and, for the <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/SPARK_(programming_language)">SPARK</a> subset, deductive verification (hand-written <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Hoare_logic">Hoare logic</a> specifications, proven via <a rel="noopener" target="_blank" href="https://people.eecs.berkeley.edu/~sseshia/pubdir/SMT-BookChapter.pdf">SMT solving</a> at compile-time).</p> <p>SPARK Ada has made <a rel="noopener" target="_blank" href="https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memory-Management-in-Ada-and-SPARK.pdf">recent advances</a> in heap memory verification. Nvidia chose it <a rel="noopener" target="_blank" href="https://www.youtube.com/watch?v=2YoPoNx3L5E">over Rust for low-level firmware</a> in 2019 - citing Rust's <a rel="noopener" target="_blank" href="https://ferrous-systems.com/blog/ferrocene-update-three-the-road/">lack of certification</a> for safety-critical systems as one consideration. But Ada hasn't quite taken off in the mainstream. Social factors - perhaps association with restrictive licenses and a proprietary compiler - have constrained adoption. Which is a shame, the language's feature set remains compelling.</p> </blockquote> <h2 id="closing-thoughts"><span class="title-sub">Closing Thoughts</span></h2> <p>What we think of as digital antiquity is, within the timescale of human existence, too recent to truly warrant the label "history". There are Ada early-adopters still employed as developers today. The GNU General Public License (GPL) is still chosen for new projects. As a child of the 90s, I have fond memories of the American Megatrends BIOS clone splash screen - illuminated via the fuzzy glow of a <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Cathode-ray_tube">CRT</a> monitor.</p> <p>The pace of technological progress is blistering. And its vector is unpredictable. Studying the past doesn't necessarily make it easier to foresee the future. It may, however, provide richer context for some of today's technologies. Or maybe just today's technical debt. Either way, our current state-of-the-art will soon be a retro curiosity relegated to a used book bargain bin. Hopefully for the better.</p> <hr /> <blockquote> <p><strong>Read a free technical book!</strong> I'm fulfilling a lifelong dream and writing a book. It's about developing secure and robust systems software. Although a work-in-progress, the book is freely available online (no paywalls or obligations): <a rel="noopener" target="_blank" href="https://highassurance.rs/">https://highassurance.rs/</a></p> </blockquote> 2022-01-04T00:00:00+00:00 2022-01-04T00:00:00+00:00 &copy; 2020-2025 Tiemoko Ballo Tiemoko Ballo https://tiemoko.com/blog/diff-fuzz/ <hr /> <p align="center"> <img src="..&#x2F;..&#x2F;images&#x2F;openssl_x509_coverage_growth.svg" alt="Coverage growth chart from openssl_x509, from Google's Fuzz Bench" style="width:100%"> <figcaption><i><center>Image source: Google's <a href="https://www.fuzzbench.com/reports/2021-06-02/index.html#openssl_x509-summary">FuzzBench project.</a> Note coverage for the OpenSSL target tapers off rather quickly.</center></i></figcaption> </p> <br> <p>The oft-cited <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Infinite_monkey_theorem">"infinite monkey theorem"</a> states that a monkey hitting utterly random keys on a typewriter will, given infinite time, manage to write the complete works of Shakespeare. That's an offensively inefficient way to reproduce classic literature. But what if your goal is to justify confidence in the correctness of a program which <em>parses</em> Shakespearean English? In a cruel twist of fate fitting of the source material: a probabilistic technique is actually one of your best options.</p> <p>Repeatedly subjecting programs to randomized and malformed inputs, aka <a rel="noopener" target="_blank" href="https://arxiv.org/pdf/1812.00140.pdf">"fuzzing" (Manes et al.)</a>, is an influential idea in software testing because, plainly, it works. Coverage-guided fuzzing, a modern variation that makes our dutiful monkeys "smarter", is a <em>largely automated</em> analysis capable of discovering critical vulnerabilities. Especially in programs written in memory-unsafe languages. Yet, despite the availability of <a rel="noopener" target="_blank" href="https://github.com/AFLplusplus/AFLplusplus">free production-grade fuzzers</a> and <a rel="noopener" target="_blank" href="https://lcamtuf.coredump.cx/afl/">their respective trophy cases of real-world bugs</a>, the technique remains criminally under-utilized in the mainstream.</p> <p>We'll start with big-picture concepts, transition to sobering truths about peer-reviewed fuzzing research, then walk through a real-world <a rel="noopener" target="_blank" href="https://llvm.org/docs/LibFuzzer.html"><code>libFuzzer</code></a> "harness" for a public Rust library (think unit test snippet, but for configuring a fuzzing campaign). Since we're targeting safe Rust code, we'll use <em>differential fuzzing</em> to demonstrate that a 3rd-party container implementation is comparable to the standard library in reliability and correctness. As opposed to fuzzing for memory corruption bugs the borrow checker <a rel="noopener" target="_blank" href="http://tiemoko.com/blog/blue-team-rust/">already protects us from</a>.</p> <p>My hope is that, armed with background knowledge and a couple of code snippets, you can make informed decisions about fuzzing in the context of software assurance - or maybe even add a harness to your next project. Note <code>libFuzzer</code> readily supports C and C++, where memory safety errors are always in scope, and our high-level methodology is transferable.</p> <h2 id="give-it-to-me-straight">Give it to me straight</h2> <p>Before we delve into the nitty-gritty tactics, let's talk strategy - what you need to know as a decision maker. Fuzzing is a dynamic program analysis with the following characteristics:</p> <ul> <li><strong>No false positives:</strong> All results are real bugs. <ul> <li>Even if they're not always exploitable vulnerabilities.</li> </ul> </li> <li><strong>High false negatives:</strong> Many, if not most, bugs are missed. <ul> <li>For reasons more complex than lack of code coverage (e.g. execution state-space not correlated with branches alone).</li> </ul> </li> <li><strong>Unbounded yield saturation:</strong> <a rel="noopener" target="_blank" href="https://blog.regehr.org/archives/1796">Groce and Reghr explain</a> why fuzzing's Return On Investment (ROI) subsides: <ul> <li>Expected returns diminish according to a <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Power_law">power law distribution</a> given constant compute resources.</li> <li>Discovering more of a given bug class may be <a rel="noopener" target="_blank" href="https://mboehme.github.io/paper/FSE20.EmpiricalLaw.pdf">linearly correlated (Bohme et al.)</a> with compute resource investment.</li> <li>Discovering bugs of <em>linearly</em> more diverse bug classes may require <a rel="noopener" target="_blank" href="https://mboehme.github.io/paper/FSE20.EmpiricalLaw.pdf"><em>exponentially</em> more (Bohme et al.)</a> investment.</li> </ul> </li> </ul> <p>All recent advances in fuzzing attempt to address the latter two shortcomings, false negatives and saturation. How they do so varies wildly: <a rel="noopener" target="_blank" href="https://users.ece.cmu.edu/~sangkilc/papers/ccs13-woo.pdf">mutation scheduling (Woo et al.)</a>, <a rel="noopener" target="_blank" href="https://www.usenix.org/system/files/sec19-blazytko.pdf">input grammars (Blazytko et al.)</a>, <a rel="noopener" target="_blank" href="https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&amp;arnumber=8835316">coverage-guidance (Nagy et al.)</a>, <a rel="noopener" target="_blank" href="https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-yun.pdf">concolic execution (Yun et al.)</a>, <a rel="noopener" target="_blank" href="https://www.usenix.org/system/files/sec20-gan.pdf">dynamic taint analysis (Gan et al.)</a>, <a rel="noopener" target="_blank" href="https://www.ndss-symposium.org/wp-content/uploads/2020/02/23096-paper.pdf">performance optimization (Schumilo et al.)</a>, etc.</p> <p>In the broader picture of a wholistic software security initiative, it's worth noting:</p> <ul> <li> <p><strong>Dynamic testing is only half of the story:</strong> Static security analyses, namely static taint analysis and certain variants of abstract interpretation, offer a complimentary set of strengths (e.g. ability to reason about all possible executions) at the cost of unique weaknesses (e.g. over-approximation and false positives). You shouldn't place all your eggs in the runtime basket.</p> <ul> <li><strong>Rust democratizes advanced static analysis:</strong> Temporal memory safety (e.g. no heap or concurrency bugs) is guaranteed at compile-time. Spatial memory safety (e.g. no buffer overflow) is run-time enforced, only where necessary. This combo enables <a rel="noopener" target="_blank" href="https://www.eurekalert.org/news-releases/610682">provable</a> safety without expensive products (like licensed code analysis tools) or hard-to-scale expert processes (like code review by skilled security engineers). So long as the developer can satisfy ownership constraints.</li> </ul> </li> <li> <p><strong>Fuzzing favors compiled binaries:</strong> Fuzzers have traditionally excelled at finding low-level failures in native code (e.g. executed directly by the CPU, like C/C++/Rust). That's the focus of this post. The bulk of relevant advances serve this niche.</p> <ul> <li><strong>The future of fuzzing is in flux:</strong> An average organization likely writes more web applications than web servers, so fuzzing of both managed code (e.g. interpreted or run in a VM, like Python/Java/TypeScript) and web APIs (see <a rel="noopener" target="_blank" href="https://mayhem4api.forallsecure.com/docs/">Mayhem4API</a> and <a rel="noopener" target="_blank" href="https://github.com/microsoft/restler-fuzzer">RESTler</a>) is increasingly relevant in industry.</li> </ul> </li> </ul> <p>Now that we have some bearing in the space, let's look at the frontier. Where the optimistic promises of the theoretical meet the crushing pressures of the practical: applied research.</p> <h2 id="are-state-of-the-art-fuzzers-just-monkeying-around">Are state-of-the-art fuzzers just monkeying around?</h2> <p>Yes and no. An honest answer requires nuance. Advances in "gray-box" techniques, coverage-guidance in particular, catalyzed a leap forward in the efficacy of practical fuzzers. Yet, despite dozens of top-tier publications and awarded PhDs, our subsequent progress hasn't proven empirically reliable. A surprising fraction of peer-reviewed algorithms aren't convincingly robust in practice.</p> <p>Before we bear the bad news, we should cover the good: evolutionary algorithms. Gray-box fuzzers leverage lightweight instrumentation to collect limited information about program internals during a run. After employing various techniques to measure program <em>coverage</em> (e.g. basic block control flow edges traversed), some gray-box fuzzers prioritize mutation of specific inputs in an effort to maximize said coverage. This strategy, dubbed "evolutionary fuzzing", tunes test populations via some notion of "fitness" - borrowing ideas from <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Genetic_algorithm">genetic algorithms</a> to generate more potent test cases. The efficacy can be shocking.</p> <p><a rel="noopener" target="_blank" href="https://lcamtuf.coredump.cx/afl/">American Fuzzy Lop (AFL)</a> was <a rel="noopener" target="_blank" href="https://www.blackhat.com/presentations/bh-usa-07/DeMott_Enbody_and_Punch/Whitepaper/bh-usa-07-demott_enbody_and_punch-WP.pdf">not the first</a> evolutionary fuzzer. But it's popularity makes it very much an integral part of the security community's zeitgeist, circa 2014 to present. AFL's coverage-hungry algorithms famously demonstrated <a rel="noopener" target="_blank" href="https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html">iteratively generating a valid JPEG</a> from scratch. Inputs generated by a traditional "black-box" (e.g. no knowledge of program internals) fuzzer would have continually failed a check early in header parsing, never exercising the majority of a JPEG library's logic. AFL could infer the relationship between a library's input and its control flow - well enough to pass checks of validity.</p> <p>To put an abstract spin on it: evolutionary fuzzing can force a small subset of state transitions in the target program's automata. See more states, find more security-relevant edge cases.</p> <p>Now for the hard truth. AFL still falls victim to the aforementioned false positive and saturation problems. In the grand scheme of things, the JPEG example is a parlor trick for which evolutionary algorithms are particularly well-suited. Fuzzing coverage <a rel="noopener" target="_blank" href="https://www.fuzzbench.com/reports/2021-06-02/index.html#openssl_x509-summary">tapers logarithmically</a> in many real-world programs without meaningful results. The evolution stops, the fuzzer gets stuck. Moreover, there exists peer-reviewed research arguing that we haven't gotten markedly better at fuzzing since AFL's 2014 debut. Two [cherry-picked] findings from that line of inquiry:</p> <ul> <li> <p><strong>Much of fuzzing research is biased and difficult to replicate.</strong> In a stern critique of contemporary work, <a rel="noopener" target="_blank" href="https://arxiv.org/pdf/1808.09700.pdf">Klees et al. (2018)</a> evaluated 32 fuzzing research papers - some of which used AFL as a baseline and claimed to develop improved fuzzers. The evaluation found serious problems in the experimental design of every surveyed paper. This implies each paper's conclusions are unreliable at best and actively misleading at worst.</p> </li> <li> <p><strong>No fuzzer, regardless of sophistication, is convincingly superior.</strong> <a rel="noopener" target="_blank" href="https://www.usenix.org/system/files/sec21summer_li-yuwei.pdf">Li et al. (2021)</a> developed a framework for metrics-based evaluation of modern fuzzers. Their open-source, head-to-head comparison of 35 state-of-the-art fuzzers found no clear winner. Judging by the <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Mann%E2%80%93Whitney_U_test">Mann-Whitney test</a> for unique bug counts, no fuzzer beat AFL across all real-world programs. Not even contenders leveraging concolic execution, a technique often touted as the holy grail of software testing.</p> </li> </ul> <p>In essence, we're still beholden to the fickle whims of chance, still just bashing keys on that metaphorical typewriter. Fuzzing is an expensive waste of resources past some specific point in time. And nobody yet knows how to reliably determine what that point is, that's <a rel="noopener" target="_blank" href="https://dl.acm.org/doi/10.1145/3339836">an area of study (Tramontana et al.)</a> in itself. Much like any research thrust, fuzzing aims to repeat and quantify phenomena we don't fully understand. It's a pursuit closer to alchemy than chemistry.</p> <h2 id="yikes-how-can-i-action-this-information">Yikes. How can I action this information?</h2> <p>One interpretation of these findings is that we have numerous monkeys each targeting different low-hanging fruit, modulo some overlap. While that's somewhat disheartening, we can double down on what works - evolutionary algorithms - and accept the limitations. At least until the periodic wave of innovation graces us with another crest. You can still get considerable value via one or more of the below strategies:</p> <ul> <li><strong>Low-effort, majority return:</strong> Use a mature coverage-guided fuzzer, if not doing so already. <ul> <li>Power law expected yield.</li> </ul> </li> <li><strong>High-effort, supplemental return:</strong> Use multiple fuzzers to increase bug yield, if compute budget allows. <ul> <li>Still power law yield, but higher bug totals on the Y-axis.</li> </ul> </li> <li><strong>Continuous effort, continuous return:</strong> <a rel="noopener" target="_blank" href="https://forum.tezosagora.org/t/how-we-utilized-fuzzing-to-improve-security-in-the-tezedge-node/3122">Integrate a fuzzer into CI</a> and continually harness newly added interfaces. <ul> <li>Likely linear yield? Assuming your team's secure coding skills have plateaued (both bug-rate and harnessing prowess).</li> </ul> </li> </ul> <p>So several typewriters are better than one, but be sure you've tried bashing at least one set of keys before you ship a product. New entry point for untrusted input appeared in code review? Ideal time to add a new harness. If a motivated attacker is the first person to fuzz your APIs...well that might reduce the universe of infinite possibilities down to a select few your Public Relations (PR) team won't be happy about.</p> <h2 id="that-s-a-cop-out-answer-we-can-do-better">That's a cop out answer. We can do better!</h2> <p>When a solution to a hard problem can't be reliably automated, we can fall back to augmenting human ability. As a Rust programmer, you've already been half of a human-in-the-loop property verification system. Those lifetime annotations <code>rustc</code> complains about? They're aiding an interprocedural static analysis. By occasionally querying your genius meat-brain for them, the compiler solves an otherwise intractable problem: eliminating memory errors.</p> <p>If carefully constructed, a harness is to a fuzzer what source annotations are to a static analyzer: a much-needed means by which to bridge the semantic gap. One particularly powerful harnessing technique is <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Differential_testing">"differential fuzzing"</a> - providing the same input to multiple programs and observing differences in their behavior. This doesn't change the fundamental calculus of the technique (no false positives, high false negatives, saturation). But it does provide richer results, enabling detection of higher-level logical errors <a rel="noopener" target="_blank" href="https://yossarian.net/res/pub/mishegos-langsec-2021.pdf">specific to the goals (Woodruff et al.)</a> of the target program.</p> <p>The beauty of differential fuzzing is that you don't need to create an abstract specification for correct behavior, at least not entirely from scratch. That creation process can be difficult and error-prone (e.g. model checking, deductive verification). Instead, our specification is provided by the programs under test. Maybe that's because one is a reference implementation written by an authority (e.g. manufacturer of device, inventor of a <a rel="noopener" target="_blank" href="https://guidovranken.com/2019/05/14/differential-fuzzing-of-cryptographic-libraries/">cryptographic algorithm</a>). Or maybe any divergence between untrusted implementations is an issue worth triaging. Either way, differential fuzzing can test domain-specific properties far exceeding the complexity of what the borrow checker is capable of reasoning about. So long as there's a counterpart to diff against.</p> <h2 id="what-s-the-goal-of-this-particular-differential-harness">What's the goal of this particular differential harness?</h2> <p>Let's start by introducing the Program Under Test (PUT), <a rel="noopener" target="_blank" href="https://docs.rs/scapegoat/latest/scapegoat/">a data-structure library</a> I've been working on. Though <a rel="noopener" target="_blank" href="https://docs.rs/scapegoat/latest/scapegoat/"><code>scapegoat</code></a> is intended as a somewhat "drop-in" (largely API-compatible) replacement for the standard library's <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/collections/struct.BTreeSet.html"><code>BTreeSet</code></a>/<a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/collections/struct.BTreeMap.html"><code>BTreeMap</code></a>, it's not as fast or mature - Rust's standard ordered set/map implementations are <a rel="noopener" target="_blank" href="http://cglab.ca/~abeinges/blah/rust-btree-case/">masterpieces of systems programming</a>.</p> <p><code>scapegoat</code> does, however, offer the following unique features:</p> <ul> <li> <p><strong><code>#![no_std]</code> portability</strong>: it'll run on embedded devices without a dynamic memory allocator and/or an OS (e.g. "bare-metal"). Collection storage is stack-allocated using compile-time, per-constructor configuration (via const generics).</p> </li> <li> <p><strong>Strictly <code>#![forbid(unsafe_code)]</code></strong>: the library, and all three of its dependencies, use <em>only</em> the safe subset of Rust. That means all emitted code maximizes memory safety guarantees for all possible executions.</p> </li> <li> <p><strong>Fallibility:</strong> <a rel="noopener" target="_blank" href="https://lkml.org/lkml/2021/4/14/1099">Out-Of-Memory (OOM) <code>panic!</code></a> is avoidable: <code>try_*</code> API variants return <a rel="noopener" target="_blank" href="https://docs.rs/scapegoat/latest/scapegoat/enum.SgError.html"><code>Result&lt;_, SgError&gt;</code></a>.</p> </li> </ul> <p>How can we be sure <code>scapegoat</code> correctly replicates the functionality of a standard library container under this set of self-imposed constraints? Relying on unit tests alone is a bit egocentric. If a developer had the omniscience to write unit tests for all possible edge cases, they'd likely also be capable of writing correct code on the first go. This is where differential fuzzing comes in.</p> <p>The remainder of this post is a hands-on tutorial in writing a differential harness for comparing <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/collections/struct.BTreeMap.html"><code>std::collections::BTreeMap</code></a> against <a rel="noopener" target="_blank" href="https://docs.rs/scapegoat/latest/scapegoat/struct.SgMap.html"><code>scapegoat::SgMap</code></a>. Repetitive per-API code is excluded for brevity (for tis <a rel="noopener" target="_blank" href="https://www.nosweatshakespeare.com/quotes/famous/brevity-is-the-soul-of-wit/">"the soul of wit"</a>!), but you can view the <a rel="noopener" target="_blank" href="https://github.com/tnballo/scapegoat/blob/master/fuzz/fuzz_targets/sg_map.rs">real harness here</a>. Our setup will be:</p> <ul> <li> <p><strong>Coverage-guided:</strong> We'll leverage granular instrumentation and genetic algorithms to automatically produce test cases that cover more of the code.</p> </li> <li> <p><strong>Structure-aware:</strong> The fuzzer's input bit-stream will be transformed into a sequence of valid library API calls and parameters. That's a best-case scenario for maximizing library coverage.</p> </li> <li> <p><strong>Differential:</strong> We'll treat the <code>std::collections</code> APIs as "known good" models, and validate that <code>scapegoat</code>'s APIs are logically equivalent (return the same results) and equally reliable (don't <code>panic!</code>).</p> </li> </ul> <p>Without further ado, let's bash some bits!</p> <h2 id="rigging-up-the-harness">Rigging Up the Harness</h2> <h3 id="0-tooling-setup"><span class="title-sub">0</span><span class="title-separator">)</span> Tooling Setup</h3> <p>We'll use <a rel="noopener" target="_blank" href="https://llvm.org/docs/LibFuzzer.html"><code>libFuzzer</code></a>: a modern, mature, open-source fuzzer. It's actively maintained as part of the LLVM compiler infrastructure project - on which Rust and many others rely. The <a rel="noopener" target="_blank" href="https://github.com/rust-fuzz/cargo-fuzz"><code>cargo-fuzz</code></a> wrapper makes using <code>libFuzzer</code> easy and fun. Assuming you already have the Rust <a rel="noopener" target="_blank" href="https://www.rust-lang.org/tools/install">toolchain installed</a> and are running x86-64 Linux or MacOS, getting set up takes just two commands:</p> <pre style="background-color:#191919;color:#ffffff;"><code><span>rustup default nightly </span><span>cargo install cargo-fuzz </span></code></pre> <p>While we need the nightly toolchain to perform fuzzing, it doesn't introduce any dependencies to stable programs being fuzzed. In other words, you can add harnesses to production libraries with low <a rel="noopener" target="_blank" href="https://rust-lang.github.io/rfcs/2495-min-rust-version.html">MSRVs</a>.</p> <p>Next, clone the below repo and initialize a harness. The repo contains <code>scapegoat</code> v2.1 code, but with a subtle bug intentionally inserted. We'll find this bug via fuzzing.</p> <pre style="background-color:#191919;color:#ffffff;"><code><span>git clone git@github.com:tnballo/diff-fuzz-blog-post.git </span><span>cd diff-fuzz-blog-post </span><span>cargo fuzz init </span></code></pre> <p>If you're on Windows, you can use the Docker container <a rel="noopener" target="_blank" href="https://github.com/tnballo/diff-fuzz-blog-post/blob/main/Dockerfile">here</a>.</p> <h3 id="1-method-dispatch-and-argument-generation"><span class="title-sub">1</span><span class="title-separator">)</span> Method Dispatch and Argument Generation</h3> <p>After running <code>cargo fuzz init</code>, you should have the following starter harness in <code>fuzz\fuzz_targets\fuzz_target_1.rs</code>:</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span style="color:#cccccc;">#![no_main] </span><span>use </span><span style="color:#cccccc;">libfuzzer_sys::fuzz_target; </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;">fuzz_target!(|</span><span style="font-style:italic;color:#8aa6c1;">data</span><span style="color:#cccccc;">: </span><span>&amp;</span><span style="color:#cccccc;">[</span><span style="color:#80d500;">u8</span><span style="color:#cccccc;">]| { </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// fuzzed code goes here </span><span style="color:#cccccc;">}); </span></code></pre> <p>The body of <code>fuzz_target</code> is <code>libFuzzer</code>'s entry point; it'll get called repeatedly with random <code>data</code> until an error condition (crash, <code>panic!</code>, <code>assert!</code> failure, etc) is found.</p> <p>To make our harness structure-aware, we need a way to convert the random, unstructured <code>data</code> stream into a sequence of calls to library APIs. Per the <a rel="noopener" target="_blank" href="https://rust-fuzz.github.io/book/cargo-fuzz/structure-aware-fuzzing.html">Rust Fuzz Book</a>, the <a rel="noopener" target="_blank" href="https://docs.rs/arbitrary/1.0.3/arbitrary/trait.Arbitrary.html"><code>Arbitrary</code> trait</a> lets us perform that conversion:</p> <ul> <li> <p>We'll create an <code>enum</code> in which each variant represents one library function and its parameters.</p> </li> <li> <p>Because our <code>enum</code> will derive <code>Arbitrary</code>, the fuzzer can choose function call order and generate parameters for each call.</p> </li> <li> <p>Every generated parameter is of the correct <em>type</em> but has an unpredictable <em>value.</em></p> </li> </ul> <p>For this post, we'll pick four map APIs to test: <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.get"><code>get</code></a>,<a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.insert"><code>insert</code></a>, <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.remove"><code>remove</code></a>, and <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#impl-Extend%3C(K%2C%20V)%3E"><code>extend</code></a>. That last interface is defined by a trait (<a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/iter/trait.Extend.html">see <code>std::iter:Extend</code></a>), but that doesn't make it special as far as writing the harness is concerned. Fuzzing trait implementations is like fuzzing any other function.</p> <p>To derive <code>Arbitrary</code>, we need to update <code>fuzz/Cargo.toml</code> to include the <a rel="noopener" target="_blank" href="https://crates.io/crates/arbitrary"><code>arbitrary</code> crate</a> as a dependency:</p> <pre style="background-color:#191919;color:#ffffff;"><code><span>[dependencies] </span><span>libfuzzer-sys = &quot;0.4&quot; </span><span>arbitrary = { version = &quot;1&quot;, features = [&quot;derive&quot;] } </span></code></pre> <p>Now we can add our API-dispatch <code>enum</code> to <code>fuzz_target_1.rs</code>, along with imports for <code>Arbitrary</code>, <code>Debug</code>, and the data structures under test:</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span style="color:#cccccc;">#![no_main] </span><span>use </span><span style="color:#cccccc;">core::fmt::Debug; </span><span>use </span><span style="color:#cccccc;">libfuzzer_sys::fuzz_target; </span><span>use </span><span style="color:#cccccc;">arbitrary::Arbitrary; </span><span>use </span><span style="color:#cccccc;">buggy_scapegoat::SgMap; </span><span>use </span><span style="color:#cccccc;">std::collections::BTreeMap; </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;">#[derive(Arbitrary, Debug)] </span><span style="color:#80d500;">enum </span><span style="color:#cccccc;">MapMethod&lt;K: Ord + Debug, V: Debug&gt; { </span><span style="color:#cccccc;"> Get { key: K }, </span><span style="color:#cccccc;"> Insert { key: K, val: V }, </span><span style="color:#cccccc;"> Remove { key: K }, </span><span style="color:#cccccc;"> </span><span style="color:#8aa6c1;">Extend </span><span style="color:#cccccc;">{ other: </span><span style="color:#8aa6c1;">Vec</span><span style="color:#cccccc;">&lt;(K, V)&gt; }, </span><span style="color:#cccccc;">} </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;">fuzz_target!(|</span><span style="font-style:italic;color:#8aa6c1;">methods</span><span style="color:#cccccc;">: </span><span style="color:#8aa6c1;">Vec</span><span style="color:#cccccc;">&lt;MapMethod&lt;</span><span style="color:#80d500;">usize</span><span style="color:#cccccc;">, </span><span style="color:#80d500;">usize</span><span style="color:#cccccc;">&gt;&gt;| { </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// fuzzed code goes here </span><span style="color:#cccccc;">}); </span></code></pre> <p>Note how we changed <code>fuzz_target</code>'s input type from <code>data: &amp;[u8]</code> to <code>methods: Vec&lt;MapMethod&lt;usize, usize&gt;&gt;</code> (both types implement <code>Arbitrary</code>). Instead of the fuzzer providing a buffer of data, it'll provide a list of function/parameter pairs. Our choice of <code>usize</code> keys and values is better for throughput than using, say, <code>String</code>s or complex <code>struct</code>s. But it doesn't hamper our ability to test ordered map logic.</p> <h3 id="2-logical-equivalence-assertions"><span class="title-sub">2</span><span class="title-separator">)</span> Logical Equivalence Assertions</h3> <p>The final piece is the body of <code>fuzz_target</code>'s closure. We need to create an instance of each data structure, iterate over <code>methods</code>, provide each input to both libraries, and check that the output and/or effect is equivalent. Here is that differential logic:</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span style="color:#cccccc;">fuzz_target!(|</span><span style="font-style:italic;color:#8aa6c1;">methods</span><span style="color:#cccccc;">: </span><span style="color:#8aa6c1;">Vec</span><span style="color:#cccccc;">&lt;MapMethod&lt;</span><span style="color:#80d500;">usize</span><span style="color:#cccccc;">, </span><span style="color:#80d500;">usize</span><span style="color:#cccccc;">&gt;&gt;| { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">const </span><span style="color:#66ccff;">CAPACITY</span><span style="color:#cccccc;">: </span><span style="color:#80d500;">usize </span><span>= </span><span style="color:#eddd5a;">2048</span><span style="color:#cccccc;">; </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let mut</span><span style="color:#cccccc;"> sg_map </span><span>= </span><span style="color:#cccccc;">SgMap::&lt;</span><span>_</span><span style="color:#cccccc;">, </span><span>_</span><span style="color:#cccccc;">, CAPACITY&gt;::new(); </span><span style="background-color:#171717;color:#616161;">// Data structure under test </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let mut</span><span style="color:#cccccc;"> bt_map </span><span>= </span><span style="color:#cccccc;">BTreeMap::new(); </span><span style="background-color:#171717;color:#616161;">// Reference data structure </span><span style="color:#cccccc;"> </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">for</span><span style="color:#cccccc;"> m </span><span>in</span><span style="color:#cccccc;"> methods { </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">match</span><span style="color:#cccccc;"> m { </span><span style="color:#cccccc;"> MapMethod::Get { key } </span><span>=&gt; </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> assert_eq!( </span><span style="color:#cccccc;"> sg_map.</span><span style="color:#8aa6c1;">get</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="color:#cccccc;">key), </span><span style="color:#cccccc;"> bt_map.</span><span style="color:#8aa6c1;">get</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="color:#cccccc;">key) </span><span style="color:#cccccc;"> ); </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> MapMethod::Insert { key, val } </span><span>=&gt; </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">if</span><span style="color:#cccccc;"> sg_map.</span><span style="color:#8aa6c1;">len</span><span style="color:#cccccc;">() </span><span>&lt;</span><span style="color:#cccccc;"> sg_map.</span><span style="color:#8aa6c1;">capacity</span><span style="color:#cccccc;">() { </span><span style="color:#cccccc;"> assert_eq!( </span><span style="color:#cccccc;"> sg_map.</span><span style="color:#8aa6c1;">insert</span><span style="color:#cccccc;">(key, val), </span><span style="color:#cccccc;"> bt_map.</span><span style="color:#8aa6c1;">insert</span><span style="color:#cccccc;">(key, val) </span><span style="color:#cccccc;"> ); </span><span style="color:#cccccc;"> assert_eq!(sg_map.</span><span style="color:#8aa6c1;">len</span><span style="color:#cccccc;">(), bt_map.</span><span style="color:#8aa6c1;">len</span><span style="color:#cccccc;">()); </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> MapMethod::Remove { key } </span><span>=&gt; </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> assert_eq!( </span><span style="color:#cccccc;"> sg_map.</span><span style="color:#8aa6c1;">remove</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="color:#cccccc;">key), </span><span style="color:#cccccc;"> bt_map.</span><span style="color:#8aa6c1;">remove</span><span style="color:#cccccc;">(</span><span>&amp;</span><span style="color:#cccccc;">key) </span><span style="color:#cccccc;"> ); </span><span style="color:#cccccc;"> assert_eq!(sg_map.</span><span style="color:#8aa6c1;">len</span><span style="color:#cccccc;">(), bt_map.</span><span style="color:#8aa6c1;">len</span><span style="color:#cccccc;">()); </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> MapMethod::Extend { other } </span><span>=&gt; </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">if </span><span style="color:#cccccc;">(sg_map.</span><span style="color:#8aa6c1;">len</span><span style="color:#cccccc;">() </span><span>+</span><span style="color:#cccccc;"> other.</span><span style="color:#8aa6c1;">len</span><span style="color:#cccccc;">()) </span><span>&lt;=</span><span style="color:#cccccc;"> sg_map.</span><span style="color:#8aa6c1;">capacity</span><span style="color:#cccccc;">() { </span><span style="color:#cccccc;"> sg_map.</span><span style="color:#8aa6c1;">extend</span><span style="color:#cccccc;">(other.</span><span style="color:#8aa6c1;">clone</span><span style="color:#cccccc;">().</span><span style="color:#8aa6c1;">into_iter</span><span style="color:#cccccc;">()); </span><span style="color:#cccccc;"> bt_map.</span><span style="color:#8aa6c1;">extend</span><span style="color:#cccccc;">(other.</span><span style="color:#8aa6c1;">into_iter</span><span style="color:#cccccc;">()); </span><span style="color:#cccccc;"> assert!(sg_map.</span><span style="color:#8aa6c1;">iter</span><span style="color:#cccccc;">().</span><span style="color:#8aa6c1;">eq</span><span style="color:#cccccc;">(bt_map.</span><span style="color:#8aa6c1;">iter</span><span style="color:#cccccc;">())); </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;"> } </span><span style="color:#cccccc;">}); </span></code></pre> <p><code>MapMethod::Get</code> and <code>MapMethod::Remove</code> are straightforward: both map implementations should return the same value, if any, because they maintain the same key-value pairs. To verify that both collections report the same length after item removal, we add the post-condition <code>assert_eq!(sg_map.len(), bt_map.len());</code>.</p> <p><code>MapMethod::Insert</code> and <code>MapMethod::Extend</code> are a tad more nuanced. Both check that <code>sg_map</code>'s fixed stack capacity won't be exceeded prior to adding items. We could have used <code>SgMap</code>'s fallible <a rel="noopener" target="_blank" href="https://docs.rs/scapegoat/latest/scapegoat/struct.SgMap.html#method.try_insert"><code>try_insert</code></a> and <a rel="noopener" target="_blank" href="https://docs.rs/scapegoat/latest/scapegoat/struct.SgMap.html#method.try_extend"><code>try_extend</code></a> to handle potential errors instead of avoiding them, but the above approach offers a more direct comparison against <code>BTreeMap</code>'s APIs. And it demonstrates a technique for encoding capacity, a factor otherwise unknown to the fuzzer, within the harness.</p> <p><code>Map::Extend</code>'s final line, <code>assert!(sg_map.iter().eq(bt_map.iter()));</code>, solves a subtle problem. After extending both collections, we'd like to ensure they contain the same items. But <code>SgMap</code> and <code>BTreeMap</code> are different types, so we can't rely on the <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/cmp/trait.Eq.html"><code>Eq</code> trait</a>. Instead, we compare their ordered iterators - which produce items of comparable type.</p> <p>These <code>assert</code>s of equivalence give <code>libFuzzer</code> a semantically rich <em>bug oracle</em>. Instead of relying on crashes, the fuzzer uses a hybrid of "state-machine" and "specification" (a formidable chimera!) to validate a complex notion of "correctness".</p> <h2 id="finding-the-bug">Finding the Bug</h2> <p>Recall that the repo for this post purposely introduces an insidious bug. It's a <em>logic bug</em> within a function for removing nodes from a binary tree. The full context of how this function works isn't important (see <a rel="noopener" target="_blank" href="https://github.com/tnballo/diff-fuzz-blog-post/blob/main/src/tree/tree.rs#L790">source</a> if interested).</p> <p>The important part is that the bug can cause our library to silently "lose" a subtree. From an end-user's perspective, this means items they insert can magically disappear. But only some of the items, and only some of the time. That's bananas!</p> <p>The original, bug-free code snippet looked like this:</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span style="color:#80d500;">loop </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> min_node </span><span>= &amp;</span><span style="color:#cccccc;">self.arena[min_idx]; </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">match</span><span style="color:#cccccc;"> min_node.</span><span style="color:#8aa6c1;">left_idx</span><span style="color:#cccccc;">() { </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// Continue search for min node </span><span style="color:#cccccc;"> </span><span style="color:#8aa6c1;">Some</span><span style="color:#cccccc;">(lt_idx) </span><span>=&gt; </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> min_parent_idx </span><span>=</span><span style="color:#cccccc;"> min_idx; </span><span style="color:#cccccc;"> min_idx </span><span>=</span><span style="color:#cccccc;"> lt_idx; </span><span style="color:#cccccc;"> } </span><span style="background-color:#171717;color:#616161;">// More code here... </span></code></pre> <p>Here's the buggy code:</p> <pre data-lang="rust" style="background-color:#191919;color:#ffffff;" class="language-rust "><code class="language-rust" data-lang="rust"><span style="color:#80d500;">loop </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">let</span><span style="color:#cccccc;"> min_node </span><span>= &amp;</span><span style="color:#cccccc;">self.arena[min_idx]; </span><span style="color:#cccccc;"> </span><span style="color:#80d500;">match</span><span style="color:#cccccc;"> min_node.</span><span style="color:#8aa6c1;">left_idx</span><span style="color:#cccccc;">() { </span><span style="color:#cccccc;"> </span><span style="background-color:#171717;color:#616161;">// Continue search for min node </span><span style="color:#cccccc;"> </span><span style="color:#8aa6c1;">Some</span><span style="color:#cccccc;">(lt_idx) </span><span>=&gt; </span><span style="color:#cccccc;">{ </span><span style="color:#cccccc;"> min_idx </span><span>=</span><span style="color:#cccccc;"> lt_idx; </span><span style="color:#cccccc;"> min_parent_idx </span><span>=</span><span style="color:#cccccc;"> min_idx; </span><span style="color:#cccccc;"> } </span><span style="background-color:#171717;color:#616161;">// More code here... </span></code></pre> <p>The bug swaps the order of the two statements nested within the <code>Some</code> match arm. That would be tricky to spot in code review, even for the eagle-eyed. I would know: this is a real bug I inadvertently introduced early in <code>scapegoat</code>'s development.</p> <p>Worse yet, the buggy library passes all <code>rustdoc</code> tests. These tests are <del>stolen</del> ported directly from <code>BTreeMap</code>'s API documentation, meaning <em>all</em> map example code works perfectly fine. The bug isn't triggered unless the internal tree is in a particular state when a particular node is removed. Because the tree is self-balancing, that state isn't trivial to reproduce. Well, unless you're using a differential fuzzer. Which can find the bad state in <em>mere seconds</em>.</p> <p>We could start the fuzzing campaign with the simple command <code>cargo fuzz run fuzz_target_1</code>, but for real-world use it's often worth augmenting the command with some of the below flags:</p> <pre style="background-color:#191919;color:#ffffff;"><code><span>cargo fuzz run fuzz_target_1 --release --debug-assertions -s address --jobs $(nproc) -- -max_len=65536 </span></code></pre> <ul> <li> <p><code>--release</code> ensures the binary is compiled with optimizations, aiding throughput.</p> </li> <li> <p><code>--debug-assertions</code> enables <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/macro.debug_assert.html"><code>debug_assert!</code> statements</a> and integer overflow checks (despite <code>release</code> mode). This flag can help catch interesting invariant violations a fuzzer would otherwise miss.</p> </li> <li> <p><code>-s address</code> enables <a rel="noopener" target="_blank" href="https://clang.llvm.org/docs/AddressSanitizer.html"><code>AddressSanitizer</code></a>, a granular instrumentation tool that can catch memory corruption errors as tiny as a single byte in size - even if the program doesn't crash or change it's output. While this needlessly lowers throughput when fuzzing a fully safe Rust program, it's a good habit to get into if you rely on <code>unsafe</code> dependencies.</p> </li> <li> <p><code>--jobs $(nproc)</code> is a Linux-ism for starting one fuzzer instance/job per available host core. On a multi-core machine, this makes fuzzing far more efficient. <code>libFuzzer</code>'s internals allow jobs to coordinate seeds/mutations among themselves.</p> </li> <li> <p><code>-max_len=65536</code> increases the upper limit length of the byte-stream produced by the fuzzer (what we're converting to API calls). The default would've still caught our crash in this example, but testing longer call sequences is generally a good idea.</p> </li> </ul> <p>Note <code>--release</code>, <code>--debug-assertions</code>, and <code>-s address</code> are default settings: they apply even if these flags are omitted. But being explicit never hurts, and the flags' functionality is worth understanding.</p> <p>After running the above command to kick-off a fuzzing campaign, you'll see terminal scroll with mutation and/or coverage information. But soon the fuzzer will find an <code>assert</code> failure! It may take a couple seconds, depending on the speed of your machine. Once the failure is found, you should see a message akin to the following buried before a stack trace:</p> <pre style="background-color:#191919;color:#ffffff;"><code><span>thread &#39;&lt;unnamed&gt;&#39; panicked at &#39;assertion failed: sg_map.iter().eq(bt_map.iter())&#39;, fuzz_targets/fuzz_target_1.rs:49:21 </span><span>note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace </span><span>==33023== ERROR: libFuzzer: deadly signal </span></code></pre> <p>Toward the bottom of the output, you'll see a command provided underneath the text <code>Minimize test case with:</code>. <code>LibFuzzer</code> has a built-in minimizer that will take a crashing input and attempt to shrink it down to the smallest possible input that still causes the same crash. Copy/paste and run this command, which should look like the below:</p> <pre style="background-color:#191919;color:#ffffff;"><code><span>cargo fuzz tmin -O -a fuzz_target_1 fuzz/artifacts/fuzz_target_1/crash-&lt;SOME_HASH&gt; </span></code></pre> <p>For the crash discovered on my machine, the minimization result was:</p> <pre style="background-color:#191919;color:#ffffff;"><code><span>Minimized artifact: </span><span> </span><span> fuzz/artifacts/fuzz_target_1/minimized-from-f4b1b840a1627a2a3b427fd923adec6aaf5c958b </span><span> </span><span>Output of `std::fmt::Debug`: </span><span> </span><span> [ </span><span> Extend { </span><span> other: [ </span><span> ( </span><span> 12225489209634957737, </span><span> 18446744073695242665, </span><span> ), </span><span> ( </span><span> 18446744073709551615, </span><span> 18446744073709551615, </span><span> ), </span><span> ( </span><span> 18446744073709551103, </span><span> 8029759142086311935, </span><span> ), </span><span> ( </span><span> 2965947086368182160, </span><span> 8214752266484842281, </span><span> ), </span><span> ], </span><span> }, </span><span> Remove { </span><span> key: 12225489209634957737, </span><span> }, </span><span> Extend { </span><span> other: [], </span><span> }, </span><span> ] </span></code></pre> <p>Now if we didn't already know where the bug is, we could manually translate this minimized call sequence into a short unit test ending with the fuzzer output's failing assert (<code>assert!(sg_map.iter().eq(bt_map.iter()));</code>). From there it's a matter of using <code>gdb</code> (or <a rel="noopener" target="_blank" href="https://rr-project.org/">Mozilla <code>rr</code></a>) to root cause the test failure. And we get to keep that unit test in our suite afterwards.</p> <p>Notice how the <code>assert</code> fires after the fuzzer calls <code>extend</code> with an empty list (last call in the sequence) and compares iterators, even though it was the previous <code>remove</code> call that caused our library to enter a "bad state". It's shockingly common for the root cause of an error to be far, in terms of SLoC or execution time, from where the error is detected. Thankfully, the minimized test case provides a full sequence of reproducible events.</p> <h2 id="takeaway"><span class="title-sub">Takeaway</span></h2> <p>A pessimist would grumble at the notion of relying on random chance to secure code. An optimist will highlight that stochastic processes are widely used in mathematical modeling to draw empirical conclusions. A realist knows the weakest link is the first to be compromised, and even the dumbest of fuzzers can find shallow bugs before an adversary does.</p> <p>Since the heyday of AFL, coverage-guided fuzzing has been the darling of dynamic security analysis. Many an academic hath dubiously claimed to build atop the shoulders of the giant. But, to again quote Shakespare completely out of context, "no legacy is so rich as honesty". And the current data indicates the coverage-guided king has yet to be convincingly dethroned.</p> <p>Rust code may seldom fall victim to the bug classes for which <a rel="noopener" target="_blank" href="https://clang.llvm.org/docs/AddressSanitizer.html"><code>AddressSanitizer</code></a> and <a rel="noopener" target="_blank" href="https://clang.llvm.org/docs/MemorySanitizer.html"><code>MemorySanitizer</code></a> are so keenly attuned. Yet fuzzing's reign is far from over. A well-designed harness can hunt down trigger-able memory corruption vulnerabilities in <code>unsafe</code> dependencies, or, in the differential case, even semantically-meaningful logic bugs.</p> <p>Run that differential fuzzer long enough and the line between fuzzing and <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Model_checking">model checking</a> starts to blur. You might be tempted to claim you've demonstrated the equivalence of <em>logical state-spaces</em> between two non-trivial programs. Informally, that could mean:</p> <blockquote> <p>An <strong>interface-level</strong>, <strong>stochastic</strong> guarantee that the <strong>internal actions</strong> of two <strong>transition systems</strong> are semantically equivalent. Where:</p> <ul> <li>The <strong>interface</strong> is defined by the APIs under test, consuming potentially attacker-controlled inputs.</li> <li><strong>Stochastic</strong> implies not absolute (constrained by limitations of dynamic testing) but powerful nonetheless.</li> <li><strong>Internal actions</strong> are "hidden" logic (e.g. inner-workings of disparate data structures backing the same API).</li> <li><strong>Transition systems</strong> are state machines represented by the real PUTs, not specifications or models.</li> </ul> </blockquote> <p>So why aren't we all fuzzing security-sensitive surfaces, at least for a modest number of cycles? Well that comes down to the difference between apes and programmers: apes <a rel="noopener" target="_blank" href="https://youtu.be/TtPXYPJ5_eE?t=423">know when</a> they should be using tools.</p> <p>Fortunately for us, <a rel="noopener" target="_blank" href="https://llvm.org/docs/LibFuzzer.html"><code>libFuzzer</code></a> (C/C++ backend/frontend) and <a rel="noopener" target="_blank" href="https://rust-fuzz.github.io/book/cargo-fuzz.html"><code>cargo-fuzz</code></a> (Rust frontend) make it delightfully easy to get those typewriters tapping. Maybe to justify confidence in our own security posture. Or, perhaps, to manifest a CVE masterpiece from the coverage-spelunking depths of someone else's code.</p> <hr /> <p><em>I'd like to thank GitHub user <a rel="noopener" target="_blank" href="https://github.com/TheDoctor314">TheDoctor314</a> for their contributions to the <code>scapegoat</code> crate, including stable-toolchain implementations of counterparts to nightly-only <code>BTreeMap</code> APIs. Much appreciated!</em></p> <hr /> <blockquote> <p><strong>Read a free technical book!</strong> I'm fulfilling a lifelong dream and writing a book. It's about developing secure and robust systems software. Although a work-in-progress, the book is freely available online (no paywalls or obligations): <a rel="noopener" target="_blank" href="https://highassurance.rs/">https://highassurance.rs/</a></p> </blockquote> 2020-07-29T00:00:00+00:00 2020-07-29T00:00:00+00:00 &copy; 2020-2025 Tiemoko Ballo Tiemoko Ballo https://tiemoko.com/blog/blue-team-rust/ <hr /> <p><em>08-02-2020 update: <a rel="noopener" target="_blank" href="https://www.reddit.com/r/rust/comments/i268wh/blue_team_rust_what_is_memory_safety_really/">Reddit discussion here</a>, <a rel="noopener" target="_blank" href="https://news.ycombinator.com/item?id=24024876">Hacker News here</a>. Appreciate all the community feedback!</em></p> <hr /> <p align="center"> <img src="..&#x2F;..&#x2F;images&#x2F;btr_mem.svg" alt="Rust Memory Safety" style="width:100%"> </p> <p>Tools shape both their user and their result. Paradigms of C and C++ have molded generations of systems programmers, the ubiquity and staying power of both languages is a testament to their utility. But the resultant software has suffered decades of <a rel="noopener" target="_blank" href="https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/">memory corruption CVEs</a>.</p> <p>Rust, as a compiled language <a rel="noopener" target="_blank" href="https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f">without garbage collection</a>, supports what have traditionally been C/C++ domains. This includes everything from high-performance distributed systems to microcontroller firmware. Rust offers an alternative set of paradigms, namely <a rel="noopener" target="_blank" href="https://depth-first.com/articles/2020/01/27/rust-ownership-by-example/">ownership and lifetimes</a>. If you've never tried Rust, imagine pair programming alongside a nearly-omniscient but narrowly-focused perfectionist. That's what the borrow checker, a compiler component implementing the ownership concept, can sometimes feel like. In exchange for the associated learning curve, we get memory safety guarantees.</p> <p>Like many in the security community, I've been drawn to Rust by the glittering promise of a safe alternative. But what does "safe" actually mean on a technical level? Is the draw one of moths to flame, or does Rust fundamentally change the game?</p> <p>This post is my attempt to answer these questions, based on what I've learned so far. Memory safety is a topic knee-deep in operating system and computer architecture concepts, so I have to assume formidable prior systems security knowledge to keep this post short-ish. Whether you're already using Rust or are just flirting with the idea, hope you find it useful!</p> <h2 id="what-exactly-are-the-memory-safety-guarantees-in-terms-of-exploitability">What exactly are the "memory safety guarantees"? In terms of exploitability?</h2> <p>Let's start with the good news. Rust largely prevents a major vector for information leakage and malicious code execution:</p> <ul> <li> <p><strong>Stack protection:</strong> Classic stack-smashing is now an <em>exception</em> and not <em>memory corruption</em>; attempts to write past the end of a buffer will trigger a panic instead of leading to <em>buffer overflow</em>. Regardless of panic handling logic (e.g. <a rel="noopener" target="_blank" href="https://crates.io/crates/panic-reset"><code>panic_reset</code></a>), your application could still be subject to <a rel="noopener" target="_blank" href="https://cwe.mitre.org/data/definitions/730.html">Denial of Service (DoS)</a> attacks. This is why fuzzing Rust is <a rel="noopener" target="_blank" href="https://blog.hackeriet.no/fuzzing-sequoia/">still worthwhile</a>. But, as the panic prevents attacker-controlled stack corruption, you won't fall victim to <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Arbitrary_code_execution">Arbitrary or Remote Code Execution (ACE and RCE, respectively)</a>. Attempts to read past the end of a buffer are similarly stopped, so <a rel="noopener" target="_blank" href="https://blog.getreu.net/projects/embedded-system-security-with-Rust/">no Heartbleed-style bugs</a>. Enforcement is dynamic: the compiler inserts runtime bounds checks where necessary, incurring small performance overhead. Bounds checks are more effective than the stack cookies a C compiler might insert because they still apply when indexing linear data structures, an operation that's easier to get right with Rust's <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/iter/index.html">iterator APIs</a>.</p> </li> <li> <p><strong>Heap protection:</strong> Bounds checks and panic behavior still apply to <a rel="noopener" target="_blank" href="https://heap-exploitation.dhavalkapil.com/">heap-allocated</a> objects. In addition, the ownership paradigm eliminates dangling pointers, preventing <a rel="noopener" target="_blank" href="https://cwe.mitre.org/data/definitions/416.html">Use-After-Free (UAF)</a> and <a rel="noopener" target="_blank" href="https://cwe.mitre.org/data/definitions/415.html">Double-Free (DF)</a> vulnerabilities: heap metadata is never corrupted. Memory leaks (meaning never freeing allocations, not over-reading data) are still possible if a programmer creates <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/book/ch15-06-reference-cycles.html">cyclical references</a>. Compile-time static analysis does the enforcement, soundly reasoning about abstract states representing all possible dynamic executions. There is no runtime cost. Effectiveness is maximal: the program simply can't enter a bad state.</p> </li> <li> <p><strong>References are always valid and variables are initialized before use:</strong> safe Rust doesn't allow manipulation of raw pointers, ensuring that pointer dereferences are valid. This means no <code>NULL</code> dereferences for DoS and no pointer manipulation for control flow hijack or arbitrary read/write. The <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/option/enum.Option.html"><code>Option</code> type</a> facilitates error handling when <code>NULL</code> is a concept the programmer wishes to <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/stable/nomicon/ffi.html#the-nullable-pointer-optimization">logically express</a>. These are compile-time guarantees, courtesy of ownership and lifetimes. A similar compile-time guarantee ensures variables can't be read until they've been initialized. Use of uninitialized variables is a warning in most modern C compilers; that aspect isn't novel. But ensuring valid dereferences certainly is.</p> </li> <li> <p><strong>Data races are completely eliminated:</strong> Rust's ownership system ensures that any given variable can only have one writer (e.g. a mutable reference) at any given program point, but an unlimited number of readers (e.g. immutable references). In addition to enabling memory safety, this scheme solves the <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Readers%E2%80%93writers_problem">classic readers-writers concurrency problem</a>. Thus Rust eliminates data races, sometimes without the need for synchronization primitives or reference counting - but not <a rel="noopener" target="_blank" href="https://youtu.be/ADbCqH7_SAs?t=669">race conditions in general</a>. Data race prevention reduces opportunities for <a rel="noopener" target="_blank" href="https://www.redballoonsecurity.com/publications/papers/Concurrency_Attacks.pdf">concurrency attacks</a>.</p> </li> </ul> <p>All good things in life come with a caveat. Let's look at the fine print:</p> <ul> <li> <p><strong>Not all Rust code is memory safe:</strong> Satisfying the compiler's analyses is part of what makes implementing certain data structures, like <a rel="noopener" target="_blank" href="https://rust-unofficial.github.io/too-many-lists/fourth.html">doubly-linked lists</a>, challenging in Rust. Moreover, certain low-level operations, like <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Memory-mapped_I/O">Memory Mapped I/O (MMIO)</a>, are difficult to <a rel="noopener" target="_blank" href="https://github.com/rust-embedded/register-rs">fully analyze</a> for safety. Blocks of code marked as <code>unsafe</code> are manually-designated "blindspots" for the analyses, relaxing safety-specific checks since the programmer vouches for their correctness. This includes parts of Rust's standard library, for which <a rel="noopener" target="_blank" href="https://gts3.org/2019/cve-2018-1000657.html">CVE numbers have been assigned</a>, and, by extension, any external libraries called via C <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Foreign_function_interface">Foreign Function Interface</a> (CFFI). Furthermore, <a rel="noopener" target="_blank" href="https://arxiv.org/abs/2003.03296">researchers have found</a> that ownership's automatic destruction can create new (meaning unique to Rust) UAF and DF patterns in <code>unsafe</code> code. <a rel="noopener" target="_blank" href="https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-silvestro.pdf">Hardened allocators</a>, which check heap consistency invariants dynamically, aren't entirely obsolete. Memory safety guarantees apply <em>broadly</em>, not <em>universally</em>.</p> </li> <li> <p><strong><code>unsafe</code> drops memory safety guarantees for a limited scope and doesn't eliminate all checks:</strong> <code>unsafe</code> isn't a free-for-all. Type, lifetime, and reference checks are still active; high-risk operations have explicit APIs (e.g. <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/std/primitive.slice.html#method.get_unchecked"><code>get_unchecked</code></a>). The CFFI boundary may be a <a rel="noopener" target="_blank" href="https://rustsec.org/advisories/RUSTSEC-2019-0005.html">weak link</a>. While memory corruption is possible with <code>unsafe</code>, the possibility is constrained to small portions of your codebase - around 1% of a typical Rust library <a rel="noopener" target="_blank" href="https://youtu.be/NQBVUjdkLAA?t=1413">by one estimate</a>. From a security audit perspective, that's a colossal reduction in attack surface for a major bug class. Think of <code>unsafe</code> as a small <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Trusted_computing_base">Trusted Computing Base (TCB)</a> in a larger system.</p> </li> <li> <p><strong>Interior mutability can push borrow checks to runtime:</strong> the <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/book/ch15-05-interior-mutability.html">interior mutability pattern</a> allows multiple mutable aliases to a single memory location so long as they're not in use simultaneously. It's a sidestep of the borrow checker, a fallback when the problem can't be <a rel="noopener" target="_blank" href="https://crates.io/crates/indextree">reframed in an idiomatic way</a> for powerful compile-time guarantees. Safe <em>wrappers</em> for <code>unsafe</code> APIs (e.g. <code>Rc&lt;RefCell&lt;T&gt;&gt;</code>, <code>Arc&lt;Mutex&lt;T&gt;&gt;</code>) verify exclusivity at runtime, incurring a performance penalty and introducing the potential to panic. I couldn't find metrics on how widely used this pattern is or isn't, but would again recommend <a rel="noopener" target="_blank" href="https://rust-fuzz.github.io/book/afl/tutorial.html">fuzzing</a> for probabilistic panic detection.</p> </li> </ul> <p>To be honest, decades of hardware, OS, and compiler-level defenses have hardened C and C++ deployments. Memory corruption 0-days aren't exactly low-hanging fruit. Yet Rust still feels like a significant step forward and a noteworthy improvement to the security posture of performance-critical software. Even though the <code>unsafe</code> escape hatch must exist, memory corruption - a large and vicious bug class - is largely eliminated.</p> <p>So is Rust the new messiah, sent to save us from the hell of remote shell? Definitely not. Rust won't stop command injection (e.g. part of an input string ending up as an argument to <code>execve</code>). Or misconfiguration (e.g. fallback to an insecure cipher). Or logic bugs (e.g. forgetting to verify user permissions). No general purpose programming language will make your code inherently secure or formally correct. But at least you don't have to worry about these kinds of mistakes <em>and</em> maintaining <a rel="noopener" target="_blank" href="https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/">complex, invisible memory invariants</a> throughout your Rust codebase.</p> <h2 id="ok-what-about-embedded-systems-aren-t-those-super-vulnerable">OK, what about embedded systems? Aren't those super vulnerable?</h2> <p>Let's assume "embedded" means no OS abstractions; the software stack is a single, monolithic binary (e.g. AVR or Cortex-M firmware) or part of the OS itself (e.g. kernel or bootloader). Rust's <a rel="noopener" target="_blank" href="http://cliffle.com/blog/m4vga-in-rust/#on-no-std"><code>#![no_std]</code> attribute</a> facilitates developing for embedded platforms. <code>#![no_std]</code> Rust libraries typically forsake dynamic collections (like <code>Vec</code> and <code>HashMap</code>) for portability to baremetal environments (no memory allocator, no heap). The borrow checker barrier is minimal without dynamic memory, so prototyping ease remains roughly equivalent to embedded C - albeit with <a rel="noopener" target="_blank" href="https://forge.rust-lang.org/release/platform-support.html">fewer</a> supported <a rel="noopener" target="_blank" href="https://gcc.gnu.org/install/specific.html">architectures</a>.</p> <p>The resource-constrained and/or real-time embedded systems <code>#![no_std]</code> targets often lack modern mitigations like <a rel="noopener" target="_blank" href="https://www.youtube.com/watch?v=Dvug1Hup2iA">a Memory Protection Unit (MPU), No eXecute (NX), or Address Space Layout Randomization (ASLR)</a>. We're talking about a lawless land where memory is flat and no one can hear you segfault. But Rust still gives us that sweet, sweet bound check insurance when running baremetal without an allocator. That's noteworthy because it might be the <em>first</em> and <em>last</em> line of defense in an embedded scenario. Just remember that low-level interaction with hardware will probably require some amount of <code>unsafe</code> code, in which memory access without bounds check is opt-in.</p> <p>For x86/x64, <em>stack probes</em> are also inserted by the Rust compiler to detect <em>stack overflow</em>. At present, this feature doesn't apply to <code>#![no_std]</code> or other architectures - although <a rel="noopener" target="_blank" href="https://blog.japaric.io/stack-overflow-protection/">creative linking solutions</a> have been suggested. Stack probes, often implemented via guard pages, prevent exhausting stack space due to unending recursion. Bounds checks, on the other hand, prevent stack or heap-based <em>buffer overflow</em> bugs. It's a subtle distinction, but an important one: for security, we typically care far more about the latter.</p> <p>Keep in mind that memory, from the perspective of Rust, is a software abstraction. When the abstraction ends, so do the guarantees. If physical attacks (side-channel attacks, fault injection, chip decapsulation, etc.) are part of your threat model, there is little reason to believe that language choice offers any protection. If you forgot to burn in the appropriate lock bits, shipped with a debug port exposed, and a symmetric key for firmware decryption/authentication is sitting in <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/EEPROM">EEPROM</a>: an attacker in the field won't need a memory corruption bug.</p> <h2 id="that-s-all-cool-but-how-about-day-to-day-development">That's all cool, but how about day-to-day development?</h2> <p>Dependency management isn't as glamorous as exploits with catchy marketing names or new-age compiler analyses to prevent them. But if you've ever been responsible for production infrastructure, you know that patch latency is often the one metric that counts. Sometimes it's your code that is compromised, but more often it's a library you rely on that puts your systems at risk. This is an area where Rust's package manager, <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/cargo/"><code>cargo</code></a>, is invaluable.</p> <p><code>cargo</code> enables composability: your project can integrate 3rd-party libraries as statically-linked dependencies, downloading their source from a centralized repository on first build. It makes dependency maintenance easier - including pulling the latest patches, security or otherwise, into your build. No analogue in the C or C++ ecosystems provides <code>cargo</code>'s <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html">semantic versioning</a>, but managing a set of <a rel="noopener" target="_blank" href="https://git-scm.com/book/en/v2/Git-Tools-Submodules">git submodules</a> could have a similar effect.</p> <p>Unlike C/C++ submodule duck tape, the aforementioned composability is memory safe in Rust. C/C++ libraries pass struct pointers around with no enforced contract for who does the cleanup: your code might free an object the library already freed - a reasonable mistake - creating a new DF bug. Rust's ownership model provides a contract, simplifying interoperability across APIs.</p> <p>Finally, <code>cargo</code> provides first-class test support, an omission modern C and C++ are often criticized for. Rust's toolchain makes the <em>engineering</em> part of software engineering easier: testing and maintenance is straightforward. In the real world, that can be as important for overall security posture as memory safety.</p> <h2 id="hold-on-didn-t-we-forget-about-integer-overflows">Hold on...didn't we forget about integer overflows?</h2> <p>Not exactly. Integer overflow isn't a memory safety issue categorically, it'd almost certainly have to be part of a larger memory corruption bug chain to facilitate ACE. Say the integer in question was used to index into an array prior to write of attacker-controlled data - safe Rust would still prevent that write.</p> <p>Regardless, integer overflows can lead to nasty bugs. <code>cargo</code> uses <a rel="noopener" target="_blank" href="https://doc.rust-lang.org/cargo/reference/profiles.html">configurable</a> build profiles to control compilation settings, integer overflow handling among them. The default <code>debug</code> (low optimization) profile includes <code>overflow-checks = true</code>, so the binary output will panic on integer overflow where the developer hasn’t made it explicit (e.g. <code>u32::wrapping_add</code>). Unless overwritten, <code>release</code> (high optimization) mode does the opposite: silent wrap-around is allowed, like C/C++, because removing the check is better for performance. Unlike C/C++, <a rel="noopener" target="_blank" href="http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/">integer overflow is not undefined behavior in Rust</a>; you can reliably expect two's complement wrap.</p> <p>If performance is priority number one, your test cases should strive for enough coverage of <code>debug</code> builds to catch the majority of integer overflows. If security is priority number one, consider enabling overflow checks in <code>release</code> and taking the availability hit of a potential panic.</p> <h2 id="takeaway"><span class="title-sub">Takeaway</span></h2> <p>Memory safety is not a new idea, garbage collection and smart pointers have been around for a while. But sometimes it's the right implementation of an existing <em>good</em> idea that makes for a novel <em>great</em> idea. Rust's ownership paradigm - which implements an <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Substructural_type_system#Affine_type_systems">affine type system</a> - is that great idea, enabling safety without sacrificing predictable performance.</p> <p>Now I [begrudgingly] aim to be pragmatic, not dogmatic. There are perfectly valid reasons to stick with a mature vendored <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Hardware_abstraction#In_operating_systems">HAL</a> and C toolchain for a production embedded project. Many existing C/C++ code bases should be fuzzed, hardened, and maintained - not re-written in Rust. Some library bindings, those of the <a rel="noopener" target="_blank" href="https://ericpony.github.io/z3py-tutorial/guide-examples.htm">z3 solver</a> being one example, greatly benefit from the dynamic typing of an interpreted language. In certain domains, languages with <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/Hoare_logic">Hoare logic</a> pre and post conditions might justify the productivity hit (e.g. <a rel="noopener" target="_blank" href="https://en.wikipedia.org/wiki/SPARK_(programming_language)">Spark Ada</a>). Physical attacks are typically language agnostic. In summary: no tool is a panacea.</p> <p>That disclaimer aside, I can't remember the last time a new technology made me stop and take notice quite like Rust has. The language crystallizes systems programming best practices in the compiler itself, trading development-time cognitive load for runtime correctness. Explicit opt-in (e.g. <code>unsafe</code>, <code>RefCell&lt;T&gt;</code>) is required for patterns that put memory at risk. Mitigation of a major bug class feels like a legitimate shift left: a notable subset of exploitable vulnerabilities become compile time errors and runtime exceptions. <a rel="noopener" target="_blank" href="https://rustacean.net/">Ferris</a> has a hard shell.</p> <hr /> <blockquote> <p><strong>Read a free technical book!</strong> I'm fulfilling a lifelong dream and writing a book. It's about developing secure and robust systems software. Although a work-in-progress, the book is freely available online (no paywalls or obligations): <a rel="noopener" target="_blank" href="https://highassurance.rs/">https://highassurance.rs/</a></p> </blockquote>