Skip to content

PATTERN Cited by 3 sources

Memory-safe language for untrusted input

A design rule: any code path that (a) processes untrusted input and (b) runs automatically (without user confirmation / step) should be written in a memory-safe language — Rust, or a managed runtime if latency / GC is acceptable.

This is a sharper rule than "use memory-safe languages everywhere" — it carves out the load-bearing subset of the codebase where memory-safety bugs translate directly into remote exploitability. It's a practical compromise for large orgs where rewriting every line isn't realistic: rewrite the untrusted-input-processing paths first, the rest at the margin.

The two ingredients

Meta's wamedia framing is the canonical articulation:

"But because media checks run automatically on download and process untrusted inputs, we identified early on that wamedia was a prime candidate for using a memory safe language."

Both properties matter:

  • Untrusted input — the attacker controls the bytes. Buffer overflows, use-after-free, bounds errors become remote-exploitable.
  • Automatic invocation — no user click, no "do you want to open this?" gate. An attacker just needs the input to arrive at the target; there's no human oversight between arrival and parsing.

Code paths where both hold are the highest-risk memory-safety targets. Code paths where only one holds are less urgent (manual invocation gives operator oversight; trusted input shifts the risk to supply-chain + pipeline integrity, see concepts/internally-generated-untrusted-input).

Canonical wiki instances

Why Rust, specifically

The Meta + DSQL + Dropbox choices land on Rust rather than a managed-runtime memory-safe language (Java, Kotlin, Go) for intersecting reasons:

  • No GC pauses on the hot path — compatible with tail-latency constraints (concepts/tail-latency-at-scale).
  • Zero-cost abstractions — the safety is compile-time; no runtime penalty for using safe types.
  • C FFI ergonomics — the untrusted-input path often has a C boundary (OS libraries, existing C codebases); Rust interoperates cleanly.
  • Cross-platform for client libraries — Rust compiles to every major platform target; no dependency on a target platform's managed runtime.

When to relax the rule

  • Trusted + manually-invoked code (admin tools, batch jobs with human oversight) — the bug/exploit path is weaker; the rule is less urgent.
  • Throwaway code (one-off scripts, prototypes, research) — life-time too short to amortise the investment.
  • Language ecosystem gap — if the memory-safe alternative lacks libraries the untrusted-input path depends on, rewriting them first may be higher-cost than hardening the C/C++ incumbent.

Companion investments

The pattern is typically adopted alongside:

  • Security assurance for the remaining C/C++ code — CFI, hardened allocators, safer buffer APIs, specialised security training, static analysis, strict SLAs on fuzz findings. Meta names this as pillar 2 of their three-pillar strategy.
  • concepts/attack-surface-minimization — shrink the reachable set before investing in the defences around it.

Seen in

Last updated · 319 distilled / 1,201 read