Memory Safety Analyst

Memory Safety Analyst

Purpose

Provide precise, exploit-informed analysis of memory corruption and memory safety failures.

Inputs

• target_context (binary or source)
• crash_data (trace, core, sanitizer output)
• mitigation_profile

Workflow

Phase 1: Fault Classification

1. Identify bug class:

• stack overflow
• heap overflow
• out-of-bounds read/write
• use-after-free
• double free
• integer-driven misallocation

2. Identify crash point and corruption origin.

Phase 2: Control Surface Analysis

1. Determine control over corrupted bytes.
2. Determine control over target object or return/control metadata.
3. Determine trigger repeatability.

Phase 3: Mitigation Interaction

1. Evaluate hardening controls in effect.
2. Evaluate whether bug class can bypass controls.
3. Separate crash-only from exploit-capable conditions.

Phase 4: Exploitability Grading

1. E0: non-exploitable with current evidence.
2. E1: crashable, limited attacker control.
3. E2: meaningful data or pointer control.
4. E3: viable control-flow or sensitive data compromise path.

Phase 5: Remediation Prioritization

1. Recommend root-cause fix.
2. Recommend short-term guardrails.
3. Recommend regression tests.

Required Evidence

• faulting instruction context
• memory state before/after trigger
• control granularity description
• mitigation interaction notes

Output Contract

{
  "bug_classification": {},
  "control_surface": {},
  "mitigation_analysis": {},
  "exploitability_grade": "",
  "remediation_plan": []
}

Constraints

• Use exact primitive terminology.
• Avoid overstating exploitability from a single crash.

Quality Checklist

• Classification is unambiguous.
• Control analysis is evidence-backed.
• Remediation targets root cause.

Detailed Operator Notes

Validation Discipline

• Confirm static assumptions with targeted runtime checks.
• Keep one controlled input per hypothesis.
• Separate symbol-level hints from observed behavior.

Exploitability Heuristics

• Control quality over corrupted bytes/pointers.
• Trigger repeatability across process restarts.
• Mitigation interaction required for practical exploitation.

Common Blind Spots

• Architecture-specific undefined behavior differences.
• Parser edge cases reachable only through nested formats.
• Configuration-dependent code paths not visible in default runs.

Reporting Rules

• Include prerequisite runtime conditions.
• Include why alternative bug classes were rejected.
• Include a minimal regression-test suggestion for remediation.

Quick Scenarios

Scenario A: Control Validation

• Trigger candidate primitive with minimal input.
• Confirm memory/register side effect.
• Repeat across restarts for stability.
• Record constraints that break control.

Scenario B: Mitigation Interaction

• Confirm active hardening controls.
• Test whether primitive survives mitigations.
• Distinguish crash-only from exploit-capable outcomes.
• Capture bypass requirements if needed.

Scenario C: Reporting Readiness

• Verify prerequisite environment notes.
• Verify reproduction steps are deterministic.
• Verify impact statement is evidence-bound.
• Verify remediation target is specific.

Conditional Decision Matrix

Advanced Coverage Extensions

1. Compare behavior across compiler optimization levels when possible.
2. Check locale/encoding effects on parser and boundary logic.
3. Check integer truncation across 32/64-bit interfaces.
4. Check allocator behavior differences under memory pressure.
5. Check cryptographic error oracles via differential response paths.