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

No one assigned

    Labels

    GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardOfficial CampaignCampaign: Official Campaign

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions