Files

T

retoorandClaude Opus 4.8 79ae6f27da cpp-safety: safe-C++ playbook, fix a second UB, and a sanitizer net

Response to incident WA-2026-10-27 (the std::vector max_size() crash). Deep
research archived under research/safe-cpp-practices (8 Tier 1, 37 Tier 2, 2
conclusions) on production-safe C++ that keeps development speed: OpenSSF
compiler hardening, the C++ Core Guidelines bounds profile, integer-overflow
practice, libFuzzer/sanitizer CI, the sanitizer overhead ladder, clang-tidy
ratchets.

The research prescribed an ASan+UBSan+_GLIBCXX_ASSERTIONS build of the parsers.
Standing it up immediately caught a second, independent undefined-behavior bug
that two manual reviews had missed: a protobuf varint loop that shifted by up
to 70 bits (shift >= 64 is UB) on malformed input. Fixed and guarded by a
deterministic test and the sanitizer net.

- src/whatsapp/wa_proto.cpp: guard the wire-0 varint shift (the UB).
- tests/whatsapp_test.cpp: add an overlong-varint hostile case.
- tools/san-whatsapp.sh: the standing sanitizer net for detz::wa parsers.
- WaClient frame capture: a frame that fails to decode/dispatch has its exact
  bytes recorded to <home>/whatsapp/last-error.log (bounded), so the still
  unreproduced live <iq> failure becomes a one-paste deterministic fix. Wired
  from the wizard and the whatsapp_send tool.
- docs/cpp-safety.md: the project-wide playbook and design decisions (four
  layers: overflow-safe checked-reader parsing, cheap release hardening, the
  sanitizer test net, capture). docs/whatsapp.md section 13.6 records the
  follow-up and the honest open item. AGENTS.md makes it a standing rule;
  cap.md and mcp.md inherit it for their wire parsers.

Verified: build, whatsapp_test (incl. hostile+fuzz), make lint, and
tools/san-whatsapp.sh all green; research audit PASS.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-10-27 19:03:32 +01:00

2.1 KiB

Raw Blame History

Coverage-guided fuzzing of parsers with libFuzzer + ASan/UBSan in CI

Metadata

Field	Value
Institute	Molodetz Institute — Research & Retrieval Division
Subject	safe-cpp-practices
Document type	Source Dossier
Tier	1
Source title	Coverage-guided fuzzing of parsers with libFuzzer + ASan/UBSan in CI
Source URL	https://appsec.guide/docs/fuzzing/c-cpp/libfuzzer/
Source publisher / author	Trail of Bits (appsec.guide); debugg.ai
Source type	vendor docs
Source date (published)	Unknown — not stated
Date researched	2026-10-27
Researched by	tai (agent), model: Claude Opus 4.8, on behalf of retoor
Research method	web search synthesis
Confidence	High
Status	Active

Summary

The standard way to harden an untrusted binary parser: a fuzz harness per entry point, built with -fsanitize=fuzzer,address,undefined and -fno-sanitize-recover, run short on every push and long nightly, with a regression corpus of past crashes rerun on every build.

Key findings

Build with -fsanitize=fuzzer,address,undefined and -fno-sanitize-recover so a finding aborts rather than warns.
One harness per untrusted-input entry point, with bounded input sizes.
Keep a regression corpus of past crashing inputs and rerun it on every build.
'No crashes' only means something if the harness reaches the risky code, so track coverage.
ASan adds ~2-4x runtime; it is a test tool, not a release one.

Pros / strengths

Concrete, matches industry practice; the regression-corpus rule is exactly what turns an unreproducible bug into a permanent test.

Cons / limitations / caveats

libFuzzer is now maintenance-only at LLVM (successor: Centipede); the CI pattern is unaffected but tool choice may shift.

Relevance to tai

detz adopts the pattern at its scale: a deterministic hostile-input test plus a random-input fuzz in whatsapp_test, run under ASan+UBSan via tools/san-whatsapp.sh, and a captured-frame file as the regression corpus seed.

Changelog

Date	Change
2026-10-27	Initial dossier created (web search synthesis).

2.1 KiB Raw Blame History