Skip to content

Plugin System Has No Sandboxing — Arbitrary Code Execution Risk #6

Description

@Nanle-code

Overview

handle_external_plugin in main.rs loads .so files via libloading with pm.load_plugin(&pl.path). This calls unsafe code that executes arbitrary native code in the same process with full user permissions. The trust system only prints a warning for unknown-source plugins — it never blocks execution. A malicious plugin could read ~/.starforge/config.toml (all wallet secret keys), exfiltrate them, or corrupt the config.

Resolution

Multi-layer hardening: (1) Add a config flag plugin_trust.require_approval = true that gates loading behind an explicit user approval stored in the registry with a content hash. Before loading, compute sha256(plugin_so_bytes) and compare against the stored approved hash — reject if mismatched. (2) Implement capability declarations in PluginDeclaration: add a capabilities: &[Capability] field (enum: NetworkAccess, FileSystem, Config) that plugins must declare at compile time. Before loading, show the user what capabilities the plugin requests and require confirmation. (3) For strong isolation, spawn the plugin in a subprocess: serialize args to stdin as JSON, deserialize stdout as the result. Pass only the minimum required context (no raw config). On Linux, use seccomp via the seccompiler crate to restrict syscalls in the child. (4) Remove the TrustLevel::Unknown warning-only path — make it a hard block by default, overridable with --allow-untrusted.

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardOfficial Campaign | FWC26Campaign: Official Campaign | FWC26

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions