Governing Unsafe FFI: Claude Mythos and Native Code Execution

Correction note (2026-10-13). The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target.

Describe the task

During a Project Glasswing audit of a Rust-based security agent, Claude Mythos identifies that a C library function is being called through FFI without proper bounds checking. The model writes a demonstration of how this could be exploited:

extern "C" {
    fn dangerous_c_func(buf: *mut u8, len: usize) -> i32;
}

unsafe {
    let mut buf = vec![0u8; 64];
    dangerous_c_func(buf.as_mut_ptr(), 1024); // overflow: len > buf capacity
}

The mismatched len parameter causes a stack buffer overflow in the C function. SSG catches the write pattern.

# illustrative sample output
[ASK] write_file › src/ffi_exploit.rs — rule: restrict-unsafe-ffi
Unsafe FFI with unchecked length parameter. Approve for controlled research?

Give SSG context

ssg hub pull @sigmashake/rules-claude-mythos

Required context

rule restrict-unsafe-ffi {
  enabled true
  priority 85
  severity error
  ASK write
  IF path ENDS_WITH ".rs"
  AND content CONTAINS "unsafe {"
  AND content CONTAINS "extern \"C\""
  AND content CONTAINS "as_mut_ptr()"
  PROMPT "Unsafe FFI with raw pointer detected. Review bounds checking before approving."
  MESSAGE "Unsafe FFI with raw pointer detected. Review bounds checking before approving."
}

Optional context

For non-research production code, promote to DENY:

rule deny-unsafe-ffi {
  enabled true
  priority 85
  severity error
  DENY write
  IF path ENDS_WITH ".rs"
  AND content CONTAINS "unsafe {"
  AND content CONTAINS "extern \"C\""
  AND content CONTAINS "as_mut_ptr()"
  MESSAGE "Unsafe FFI in production Rust code requires security review. File a security ticket."
}

What SSG does

SSG detects the combination of unsafe blocks, extern "C" declarations, and raw pointer usage — a high-signal pattern for FFI code that may have exploitable memory safety issues. The ASK decision routes the write to a human reviewer rather than blocking outright, since FFI is sometimes legitimately necessary.

Ask the agent to add bounds validation

Unsafe FFI was flagged. Before approving, verify:
1. The `len` parameter matches the actual buffer capacity
2. The C function validates bounds internally OR the Rust caller enforces them
3. The code uses slice::from_raw_parts with validated lengths

Rewrite with:
  assert!(len <= buf.len(), "buffer overflow: len exceeds capacity");
  dangerous_c_func(buf.as_mut_ptr(), buf.len());

Require a safety comment for all unsafe blocks

Enforce Rust's best practice of documenting why every unsafe block is sound:

rule require-unsafe-comment {
  enabled true
  priority 70
  severity warning
  ASK write
  IF path ENDS_WITH ".rs"
  AND content CONTAINS "unsafe {"
  AND content NOT CONTAINS "// SAFETY:"
  AND content NOT CONTAINS "// Safety:"
  PROMPT "unsafe block missing SAFETY comment. Document why this is sound."
  MESSAGE "unsafe block missing SAFETY comment. Document why this is sound."
}

How the pattern avoids false positives

The rule requires all three conditions: unsafe, extern "C", and as_mut_ptr(). Code using unsafe for internal Rust operations without FFI doesn't trigger the rule. Code using FFI without raw pointer passing also doesn't trigger.

Check the rule against your embedded systems code

Embedded and systems Rust code may require unsafe FFI with hardware registers. Use a path exclusion for src/hal/ or src/drivers/ combined with a stricter code review process outside SSG.