Week 11 · readme

Week 11 — Memory-Safety & Exploitation

← all weeks · worksheet · slides

Week 11 — Memory-Safety & Exploitation

(Merges the former Memory-Safety and Reverse-Engineering weeks into one.)

CWE: CWE-787 (out-of-bounds write), CWE-121 (stack overflow), CWE-416 (use-after-free), CWE-134 (format string), CWE-193 (off-by-one)

✅ This week — what to do

  1. Before class — Docker Desktop working (Week 1 Lab 0); skim last week's recap.
  2. Lecture (120 min) — weekly quiz first (~10 min), then the lecture. Slides: slides/week11.md.
  3. Lab (180 min) — play this week's game, then complete Worksheet 11 (worksheet.md, Parts 1–4, incl. Audit the AI + EiPE/Prompt). Kickoff: in the toolbox container (labs/toolbox), run clang -fsanitize=address,fuzzer fuzz_harness.c -o fuzz && ./fuzz.
  4. Submit — worksheet PDF → Classroom · code → GitHub · weekly quiz → Google Form. (How: SUBMISSION.md.)
  5. Project — apply this week's lesson to your NoteVault project where it fits.

Time breakdown: AGENDA.md. Grading: see the worksheet rubric.

Objectives

  • Explain the C/C++ memory model and the stack frame.
  • Find bugs with coverage-guided fuzzing, then exploit a stack overflow / format-string bug to redirect control flow.
  • Read disassembly/decompilation (Ghidra/gdb) to locate a vulnerable function.
  • Understand modern mitigations (ASLR, stack canaries, NX/DEP) and the global shift to memory-safe languages (Rust/Go) — see the Secure by Design / CISA & ONCD memory-safety roadmaps.

💥 Signature game — "Fuzzing Race → Pwn the Binary"

A small vulnerable C binary is provided — build/run it only inside the isolated toolbox container (or a VM).

Round 1 — Fuzzing Race (find the bug): first team to crash the target wins.

# coverage-guided fuzzing
clang -fsanitize=address,fuzzer harness.c -o fuzz && ./fuzz        # libFuzzer
# or
afl-cc vuln.c -o vuln.afl && afl-fuzz -i seeds -o out -- ./vuln.afl @@   # AFL++

Round 2 — Pwn the Binary (exploit):

gcc -fno-stack-protector -z execstack -no-pie vuln.c -o vuln   # teaching build
  1. Find the offset to the return address (pattern/cyclic).
  2. Overwrite the return address to reach a win() function (or use the format-string bug to leak/overwrite memory).
  3. Re-compile with canaries + ASLR + PIE and observe how the exploit breaks.

Round 3 — Defend: rewrite the vulnerable routine with bounds-safe APIs, then port it to Rust and explain why the bug class becomes impossible. Tie it back to why industry/government is mandating memory-safe languages.

Deliverable

Fuzzing crash + exploit script + annotated decompilation + a memory-safe (Rust) rewrite, with a short note on how each mitigation changed the attack.

References

  • https://cheatsheetseries.owasp.org/cheatsheets/Memory_Management_Cheat_Sheet.html
  • https://github.com/AFLplusplus/AFLplusplus · https://llvm.org/docs/LibFuzzer.html
  • https://github.com/NationalSecurityAgency/ghidra · https://picoctf.org/
  • CISA "The Case for Memory Safe Roadmaps" — https://www.cisa.gov/resources-tools/resources/case-memory-safe-roadmaps