Ysopwnableandgensokyo-dev
559083be29
* docs(security): define REA threat model and security properties * docs(security): clarify the HTTP MCP trust boundary --------- Co-authored-by: gensokyo-dev <gensokyo-dev@users.noreply.github.com>
7.8 KiB
Security Policy
Supported versions
Security fixes are provided for the latest published version of REA. Upgrade to the latest release before reporting a problem that may already have been resolved.
Security boundary
REA is a local reverse-engineering and automation tool. CLI and MCP use the same application workflows and run with the host process's permissions. REA is not a general-purpose sandbox or a multi-tenant authorization service.
Threat model
- Trusted authority: the operating-system account running REA, the caller or agent host that selects operations, and configured analysis providers, their executables and extensions, and service endpoints. An MCP client can invoke the operations exposed to it; its host must enforce the user's tool permissions and approvals.
- Untrusted data: target binaries, archives, source files, project contents, captures, web pages and returned target content can be malicious. Selecting an input for static inspection does not authorize commands embedded in that input. Agents must treat target text and Evidence as data rather than instructions granting additional authority.
- Operation-specific effects: static inspection parses target data and may launch an analysis engine. Runtime, debugger, instrumentation, browser, desktop and environment workflows can deliberately execute code, attach to processes, make network requests, write files or interact with applications and devices. Review the selected operation's effects and limitations; static inspection does not authorize launching or interacting with the target application. See runtime and network responsibilities.
Standard client registrations use a dedicated stdio process. Opt-in HTTP MCP uses plain HTTP without TLS or client authentication and shares provider/active-target state across protocol sessions. Its session ID is not a user-authentication or isolation boundary. Keep this endpoint within a trusted local or isolated environment.
Intended security properties
Static JavaScript and .NET inspection do not run the target application. Unexpected execution of input code through a data-only analysis path is a security concern. Analysis engines themselves are executable software trusted with the host account's permissions; parsing an input in an external engine does not isolate that engine from the host.
REA authenticates its managed Hopper and Ghidra bridges with per-session random capability tokens transferred through private session files, rather than process arguments or environment variables. POSIX uses current-user Unix sockets. Windows Ghidra uses authenticated loopback TCP and a private NTFS runtime whose DACL admits only the current user and SYSTEM. These controls protect the managed session boundary, not every external provider or debugger endpoint. See Windows Ghidra transport and lifecycle.
Provider ownership and mutation rules remain specific to each workflow:
- Ghidra's working projects are temporary and owned by REA. Opt-in checkpoints retain REA-owned Program state. A caller-selected existing project is fingerprinted and copied into an owned runtime for read-only processing; Ghidra does not open or save the original database through that workflow.
- IDA analysis is read-only. An attached GUI database is never saved or closed by REA; owned headless sessions have a separate lifecycle.
- Cleanup must stay within resources REA owns. Failed or unverified cleanup can retain a workspace or session for retry; closing a session does not imply that every investigation artifact has been erased.
rea setup shows planned configuration and installation changes and requires
approval before applying them. Ghidra, Java and IDA are user-managed. Approved
Linux Hopper installation authenticates the package's detached PGP signature
against the pinned publisher identity and checks the signed launcher against
the selected release's digest. The release feed's display version is separate
from that authenticated identity. See installation and publisher verification.
Limits and caller responsibilities
- Host isolation: private runtimes and capability tokens do not protect against malicious software already running as the same operating-system user, or a compromised trusted client or provider. Use an appropriately isolated account, VM or restricted environment when handling hostile targets.
- Resource bounds: timeouts, cancellation, streaming and size limits are operation-specific. They are not a universal CPU, memory, disk or wall-time limit on every target and third-party tool. Enforce hard host resource limits externally when needed. Failures of a documented boundary or cancellation control still warrant investigation.
- Data and network exposure: Evidence, caches, checkpoints, exports and captures can retain private target data, paths, URLs and memory contents. Local execution does not make these outputs safe to publish. Requested network operations, agent hosts and provider features such as IDA Free's cloud decompiler can communicate outside the host. Review their data handling and secure any exposed endpoint.
- Interpretation: analysis, reconstruction and generated environments can be incomplete or incorrect. Identity checks, signatures and successful analysis do not establish that a target, provider or generated program is safe to execute. Review the Evidence and proposed actions before relying on them.
Vulnerability scope
Please report suspected violations of these boundaries privately. Examples include unintended code execution during data-only inspection, escaping a documented extraction/output boundary, bypassing bridge authentication or target/session identity checks, unauthorized effects on an unrelated resource, and disclosure of transport credentials or explicitly marked sensitive values. An attacker-triggered bypass of a documented resource or cancellation control can also be security-relevant without code execution.
Incorrect analysis, unsupported formats, crashes, hangs and high resource use without a security-boundary impact are generally ordinary bug reports. Effects explicitly requested through an execution or interaction workflow are not by themselves a vulnerability. A dependency advisory needs its actual REA exposure assessed; a complete exploit or diagnosis is not required to report a concern. If you are unsure whether a boundary is affected, use the private channel below.
Reporting a vulnerability
Do not disclose vulnerabilities, proof-of-concept exploits, credentials, private binaries, Hopper documents, or private Ghidra projects in a public issue.
Use Report a vulnerability in the repository's Security tab as the preferred way to submit the report privately. If GitHub private reporting is unavailable to you, email morluto@outlook.com. Do not open a public issue to request a private contact channel.
Include the affected REA version, operating system/distribution, selected provider and version, impact, reproduction conditions, and any suggested mitigation in the private report. Remove credentials, proprietary binaries, Hopper documents, Ghidra project contents, socket capability tokens, and unrelated local paths from logs or examples.
The maintainer will acknowledge the report, assess its scope, and coordinate remediation and disclosure timing with the reporter. Please allow time for provider-dependent behavior to be reproduced safely.