CVE Casebook - From Advisory to Durable Engineering Control

Use public vulnerabilities to learn failure classes, not to collect payloads. Reproduce only a minimal analogue in the purpose-built labs. For every case, separate:

bug -> reachable attack surface -> violated trust boundary -> demonstrated effect
    -> plausible impact -> mitigations -> patch invariant -> variants -> detection

Case 1 - Heartbleed, CVE-2014-0160

Primary source: OpenSSL advisory

Failure class: an untrusted length was accepted without proving that the corresponding bytes existed, allowing an out-of-bounds read. The important lesson is not TLS-specific: metadata cannot authorize memory access.

Safe exercise: use C Memory Corruption. Change the toy parser into an over-read, capture ASan, minimize the input, and fix the root contract: declared_length <= available_length <= configured_limit.

Defense:

  • parse fixed headers only after proving they exist;
  • perform checked integer conversion before pointer arithmetic or allocation;
  • require exact consumption where trailing bytes are invalid;
  • fuzz boundary values and compile native code under ASan/UBSan in CI;
  • inventory vulnerable versions, rotate potentially exposed secrets, and retain patch evidence.

Variant hunt: sibling message types, alternate protocol versions, signed/unsigned conversions, zero-copy paths, compression paths, and error-reporting code that echoes buffers.

Case 2 - Log4Shell, CVE-2021-44228

Primary source: Apache Logging Services security advisories

Failure class: attacker-controlled text crossed from inert data into a powerful lookup and naming mechanism. Reachability depended on dependency versions, configuration, runtime behavior, and where untrusted values entered logging.

Safe exercise: do not stand up an internet-reachable vulnerable service. Extend JVM Deserialization with a harmless in-memory callback to demonstrate why data-to-code transitions are dangerous. Build an SBOM query that finds affected coordinates and a regression test proving logged input is treated as data.

Defense:

  • upgrade to the vendor-fixed release; do not rely on string filters;
  • remove obsolete lookup/deserialization features and minimize runtime modules;
  • block unnecessary application egress and DNS, especially from parsers and log processors;
  • inventory shaded/transitive JARs and long-lived images, then redeploy rather than only restarting;
  • detect unexpected child processes, outbound naming traffic, new class loads, and configuration drift while acknowledging that detections are not the patch.

Variant hunt: alternate logging entry points, exception messages, headers, MDC/context fields, message brokers, enrichment pipelines, vulnerable shaded copies, and configuration reload paths.

Case 3 - runc container escape, CVE-2019-5736

Primary source: runc 1.0.0-rc6 security release

Failure class: a container process could abuse host-runtime execution and file/proc semantics to overwrite the runtime binary. A container is a process-isolation mechanism sharing a kernel, not a VM boundary.

Safe exercise: never reproduce an escape on a shared host. In Sandbox Policy, reject runtime sockets, host namespaces, writable host paths, privileged execution, and unnecessary capabilities. Then compare rootless containers, gVisor, and a Firecracker microVM for an untrusted parser.

Defense:

  • patch the runtime everywhere, including nodes not currently scheduling workloads;
  • drain/rebuild nodes when the threat model requires confidence about host integrity;
  • prohibit privileged containers, runtime sockets, host PID/mount namespaces, and broad hostPath;
  • use read-only images/filesystems, seccomp, LSM policy, capabilities reduction, rootless operation, and stronger isolation for hostile workloads;
  • alert on runtime binary changes, sensitive proc-file access, unexpected mounts, and node drift.

Variant hunt: leaked file descriptors, procfs assumptions, helper binaries, hooks, writable runtime state, exec/attach paths, and differences among create/start/exec operations.

Case 4 - runc "Leaky Vessels", 2024 runtime advisories

Primary source: OpenContainers advisory GHSA-xr7r-f8xq-vfvv

Failure class: file descriptors and working-directory state crossed an isolation boundary. This is a powerful review lesson: ambient process state is authority.

Safe exercise: extend the MicroVM Lifecycle state machine with a launch manifest that closes unknown descriptors, sets a known working directory, uses close-on-exec, and proves cleanup after cancellation.

Defense and variants: patch runc and downstream products; inspect descriptor inheritance, O_CLOEXEC, /proc/self/fd, current working directory, bind mounts, hooks, console descriptors, error paths, and subprocess launch wrappers. Add regression tests that enumerate inherited descriptors from inside the sandbox.

Case 5 - ingress-nginx admission controller, CVE-2025-1974

Primary source: Kubernetes project advisory and mitigation guide

Failure class: an admission component accepted powerful configuration while reachable over the pod network and running with access that could expose cluster secrets. The chain combined input validation, network reachability, generated configuration, and service-account authority.

Safe exercise: use Kubernetes Admission to reject dangerous pod settings, then model the webhook as a high-value service. Add a default-deny NetworkPolicy, explicit API-server ingress, least-privilege service account, immutable image, read-only filesystem, and upgrade gate. Do not deploy a vulnerable controller.

Defense:

  • inventory affected controller versions and follow the Kubernetes/vendor upgrade guidance;
  • restrict admission-webhook reachability and controller egress;
  • minimize mounted service-account tokens and RBAC;
  • validate generated configuration as code, not merely YAML shape;
  • monitor admission changes, controller config reloads, unusual secret reads, and unexpected controller-to-workload traffic.

Variant hunt: annotations/snippets, template and module loading, validation-to-generation gaps, other controllers with configuration-language features, webhook failure policy, and stale replicas.

Required case-study deliverable

For one CVE, submit:

  1. affected-version and deployment inventory;
  2. trust-boundary and precondition diagram;
  3. safe toy reproduction or documented reason not to reproduce;
  4. patch diff and invariant;
  5. regression and five-variant test plan;
  6. fleet remediation and rollback plan;
  7. detection hypotheses with false-positive limits;
  8. evidence manifest and an executive update that avoids unsupported exploitability claims.

CVSS is an input, not the conclusion. Environment reachability, privileges, data sensitivity, control effectiveness, and recovery cost determine operational priority.