morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4248] [Feature] Add a provider-neutral MCP prompt for static vulnerability review of native binaries #1672

New issue

Open

opened 2026-10-16 21:08:52 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:08:52 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4248

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

MCP or agent integration

Current limitation

CONTRIBUTING.md lists vulnerability analysis as supported, and REA already has the pieces for a static native review: mitigation inferences from inspect_binary_layout and inspect_signature, sink lookup through list_names, find_xrefs_to_name, and search_procedures, function context from analyze_function and trace_native_values, call paths from trace_call_path and build_call_path, and gap tracking with record_unknown. None of the six MCP prompts (docs/mcp-prompts.md) composes them for this task, and the bundled skill has no vulnerability section. An agent starting a review has no REA-provided starting points and no REA-provided wording on how to separate a reachable path, an inferred controllable input, and an unknown, so its output depends on its own habits and can overclaim exploitability.

Use cases

Reviewing a self-built or authorized parser binary for memory-safety defects before release.
Triaging a fuzzing crash site: is the faulting function reachable from an input-handling entry point, and what mitigations apply?
Producing a remediation-oriented write-up in which every claim cites Evidence.

Desired outcome and success criteria

One new prompt (name to be chosen, for example review_native_vulnerabilities) in PROMPT_CONTRACTS that renders guidance only and executes nothing. Success criteria:

It takes a required review focus (an input parser, entry point, or sink class) and optional target, document, procedure, and provider arguments with the existing completion kinds.
Its steps suggest existing read-only tools only: mitigation facts, sink imports and their cross-references, function dossiers and value tracing, call paths toward entry points, indirect-call resolution, and record_unknown. It suggests no process capture, Frida, debugger, or raw-command tools.
Its objective requires a three-way classification for each candidate defect: a statically observed path cited by Evidence; input controllability as Inference with confidence; and Unknown when no static path was found or indirect calls are unresolved.
It labels CWE classes and severity as Inference, reports mitigations as the static inferences the tools return (never as proof of protection or its absence), and records unavailable mitigation facts as Unknown.
It states that the output is a defensive, remediation-oriented review and excludes exploits, payloads, shellcode, ROP or JOP chains, heap-grooming recipes, and mitigation-bypass techniques; naming a trigger condition or precondition is enough.
docs/mcp-prompts.md and the prompt boundary tests cover the new prompt, and its text renders the shared Evidence discipline.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Guidance over existing tools; adds no tool, no execution authority, and no analysis logic. Non-goals: a built-in sink or CWE catalog in code, exploitability scoring, Android or script variants (REA lacks structured exported-component and intent facts, so an Android prompt would mostly say "read the manifest text"), and any runtime step. This differs from the closed #43, #368, and #369, which asked for a broad playbook catalog and schema with no implementation: this is one concrete contract built on existing machinery. Adding a prompt changes prompts_sha256 in the catalog identity, so connected clients will see a restart-required change.

Verification available so far

Idea only; I need help defining checks

Verification details (optional)

Boundary tests in tests/boundary/mcp/promptMcp.test.ts already render every contract; the new prompt needs a minimum-arguments entry there and an assertion that the rendered text contains the exclusion wording and lists only read-only tools. A manual check: run the prompt in a client against a self-compiled ELF that copies argv[1] into a stack buffer with strcpy, built with and without -fstack-protector, and confirm that the review cites the strcpy cross-reference, the call path from main, and the canary inference, and labels controllability as Inference.

Alternatives considered

Skill guidance only: does not reach MCP clients that do not load REA's skill.
A general playbook catalog: already declined as premature in #43.
External report tooling (#1142, PR #3812): covers reporting verdicts after an investigation, not guiding the investigation.

Possible direction

Base the objective and steps on a conventional native review checklist and exploitability wording: CWE-tagged objectives for out-of-bounds write and read, stack and heap overflow, integer overflow, format string, command injection, use-after-free, and double free; a sink list of strcpy, strcat, sprintf, gets, memcpy, alloca, system, popen, and exec*; a three-tier wording of "reachable and controllable", "reachable but input not obviously controllable", and "no static path found (indirect calls may still exist)"; and a requirement to note canaries, NX, ASLR, and RELRO. Keep the sink list as prompt prose, not a code catalog, so it composes tools rather than duplicating analysis (the rule from #102).

References

REA baseline: main at 0cc56493be (package 6.5.0): src/contracts/promptContracts.ts (COMMON_DISCIPLINE at lines 52-57), src/server/registerPrompts.ts, docs/mcp-prompts.md, docs/binary-diagnostics.md:82-85, docs/tool-design.md:38.
Related, not duplicates: #43, #368, #369 (closed playbook catalog), #102 and PR #104 (origin of the prompts), #3954 (prompt objective wording reviewed for execution drift), #969 (mitigations are evidence, not exploitability conclusions), #1142 and PR #3812 (reporting).
Search: all issues and pull requests were listed and searched locally for vulnerability, CWE, checksec, mitigation, prompt, playbook, sink, audit, exploit, and hardening; no existing proposal for a vulnerability-review prompt found.

Originally created by @coygeek on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4248 ### Before submitting - [X] I searched the open and closed issues and pull requests for a related proposal. - [X] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [X] This request does not include credentials, private samples, or sensitive target data. ### Area MCP or agent integration ### Current limitation `CONTRIBUTING.md` lists vulnerability analysis as supported, and REA already has the pieces for a static native review: mitigation inferences from `inspect_binary_layout` and `inspect_signature`, sink lookup through `list_names`, `find_xrefs_to_name`, and `search_procedures`, function context from `analyze_function` and `trace_native_values`, call paths from `trace_call_path` and `build_call_path`, and gap tracking with `record_unknown`. None of the six MCP prompts (`docs/mcp-prompts.md`) composes them for this task, and the bundled skill has no vulnerability section. An agent starting a review has no REA-provided starting points and no REA-provided wording on how to separate a reachable path, an inferred controllable input, and an unknown, so its output depends on its own habits and can overclaim exploitability. ### Use cases - Reviewing a self-built or authorized parser binary for memory-safety defects before release. - Triaging a fuzzing crash site: is the faulting function reachable from an input-handling entry point, and what mitigations apply? - Producing a remediation-oriented write-up in which every claim cites Evidence. ### Desired outcome and success criteria One new prompt (name to be chosen, for example `review_native_vulnerabilities`) in `PROMPT_CONTRACTS` that renders guidance only and executes nothing. Success criteria: - It takes a required review focus (an input parser, entry point, or sink class) and optional target, document, procedure, and provider arguments with the existing completion kinds. - Its steps suggest existing read-only tools only: mitigation facts, sink imports and their cross-references, function dossiers and value tracing, call paths toward entry points, indirect-call resolution, and `record_unknown`. It suggests no process capture, Frida, debugger, or raw-command tools. - Its objective requires a three-way classification for each candidate defect: a statically observed path cited by Evidence; input controllability as Inference with confidence; and Unknown when no static path was found or indirect calls are unresolved. - It labels CWE classes and severity as Inference, reports mitigations as the static inferences the tools return (never as proof of protection or its absence), and records unavailable mitigation facts as Unknown. - It states that the output is a defensive, remediation-oriented review and excludes exploits, payloads, shellcode, ROP or JOP chains, heap-grooming recipes, and mitigation-bypass techniques; naming a trigger condition or precondition is enough. - `docs/mcp-prompts.md` and the prompt boundary tests cover the new prompt, and its text renders the shared Evidence discipline. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Guidance over existing tools; adds no tool, no execution authority, and no analysis logic. Non-goals: a built-in sink or CWE catalog in code, exploitability scoring, Android or script variants (REA lacks structured exported-component and intent facts, so an Android prompt would mostly say "read the manifest text"), and any runtime step. This differs from the closed #43, #368, and #369, which asked for a broad playbook catalog and schema with no implementation: this is one concrete contract built on existing machinery. Adding a prompt changes `prompts_sha256` in the catalog identity, so connected clients will see a restart-required change. ### Verification available so far Idea only; I need help defining checks ### Verification details (optional) Boundary tests in `tests/boundary/mcp/promptMcp.test.ts` already render every contract; the new prompt needs a minimum-arguments entry there and an assertion that the rendered text contains the exclusion wording and lists only read-only tools. A manual check: run the prompt in a client against a self-compiled ELF that copies `argv[1]` into a stack buffer with `strcpy`, built with and without `-fstack-protector`, and confirm that the review cites the `strcpy` cross-reference, the call path from `main`, and the canary inference, and labels controllability as Inference. ### Alternatives considered - Skill guidance only: does not reach MCP clients that do not load REA's skill. - A general playbook catalog: already declined as premature in #43. - External report tooling (#1142, PR #3812): covers reporting verdicts after an investigation, not guiding the investigation. ### Possible direction Base the objective and steps on a conventional native review checklist and exploitability wording: CWE-tagged objectives for out-of-bounds write and read, stack and heap overflow, integer overflow, format string, command injection, use-after-free, and double free; a sink list of `strcpy`, `strcat`, `sprintf`, `gets`, `memcpy`, `alloca`, `system`, `popen`, and `exec*`; a three-tier wording of "reachable and controllable", "reachable but input not obviously controllable", and "no static path found (indirect calls may still exist)"; and a requirement to note canaries, NX, ASLR, and RELRO. Keep the sink list as prompt prose, not a code catalog, so it composes tools rather than duplicating analysis (the rule from #102). ### References - REA baseline: `main` at 0cc56493be167309bd72040273de603ad75ad9e0 (package 6.5.0): `src/contracts/promptContracts.ts` (`COMMON_DISCIPLINE` at lines 52-57), `src/server/registerPrompts.ts`, `docs/mcp-prompts.md`, `docs/binary-diagnostics.md:82-85`, `docs/tool-design.md:38`. - Related, not duplicates: #43, #368, #369 (closed playbook catalog), #102 and PR #104 (origin of the prompts), #3954 (prompt objective wording reviewed for execution drift), #969 (mitigations are evidence, not exploitability conclusions), #1142 and PR #3812 (reporting). - Search: all issues and pull requests were listed and searched locally for vulnerability, CWE, checksec, mitigation, prompt, playbook, sink, audit, exploit, and hardening; no existing proposal for a vulnerability-review prompt found.

bsakaguchi commented

2026-10-16 21:08:53 +00:00

Author

Owner

@dayvison2b commented on GitHub (Oct 15, 2026):

I can take this one. I'll add the read-only MCP prompt and cover the guidance in the prompt tests and docs.

@dayvison2b commented on GitHub (Oct 15, 2026): I can take this one. I'll add the read-only MCP prompt and cover the guidance in the prompt tests and docs.

bsakaguchi referenced this issue

2026-10-31 00:54:35 +00:00

[PR #1672] [CLOSED] feat(ghidra): surface instruction-backed prototype conflicts #4743

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1672

No description provided.

Rows
Columns