src/agents/bash-tools.exec.ts:1
[AGENTS: Chaos, Cipher, Compliance, Egress, Exploit, Fuse, Gateway, Harbor, Infiltrator, Lockdown, Mirage, Passkey, Phantom, Prompt, Razor, Recon, Siege, Supply, Trace, Tripwire, Vault, Vector, Wallet, Warden, Weights]api_security, attack_chains, attack_surface, business_logic, configuration, containers, credentials, cryptography, data_exfiltration, denial_of_wallet, dependencies, dos, edge_cases, edge_security, error_security, false_confidence, info_disclosure, llm_security, logging, model_supply_chain, privacy, regulatory, secrets, security, supply_chain
**Perspective 1:** This exec tool allows LLMs to execute shell commands with parameters like workdir, env, background execution, and elevated privileges. LLM-generated commands are executed directly on the host system. While there are security levels (deny/allowlist/full) and approval mechanisms, the tool validates script files for shell variable injection but doesn't prevent other types of command injection.
**Perspective 2:** The exec tool executes shell commands with user-controlled input. While there are some validation mechanisms, the command is passed directly to shell execution without proper sanitization against shell metacharacters. The tool allows background execution, PTY mode, and elevated privileges which could be exploited for privilege escalation or persistence.
**Perspective 3:** While the tool uses exec-safe-bin-runtime-policy, the command parsing in extractScriptTargetFromCommand uses simple regex that could be bypassed with clever quoting or shell metacharacters, potentially allowing injection.
**Perspective 4:** The elevated command execution feature uses simple boolean checks (elevatedDefaults?.enabled && elevatedDefaults.allowed) without proper role-based access control or multi-factor authentication. PCI-DSS and SOC 2 require strict access controls for privileged operations, including separation of duties and least privilege principles.
**Perspective 5:** The exec tool executes shell commands with various parameters but relies on external validation (gateway allowlist, safe bins). The preflight validation for script files is basic and could miss complex injection vectors.
**Perspective 6:** The exec tool executes shell commands with parameters that could be vulnerable to injection if not properly sanitized. The validateScriptFileForShellBleed function attempts to detect shell variable injection but may not catch all cases.
**Perspective 7:** The exec tool allows shell command execution with configurable security levels (deny, allowlist, full), background execution, and elevated privileges. It supports host routing (sandbox, gateway, node) and can bypass approvals when elevatedMode is 'full'. The tool validates scripts for shell variable injection but doesn't prevent other injection vectors. Background processes can continue running after tool call completion.
**Perspective 8:** The exec tool allows arbitrary shell command execution with background continuation. While there are security controls, there are no cost-based limits on compute time, memory usage, or spawned processes. An attacker could run resource-intensive commands (mining, compression, infinite loops) that consume CPU/memory indefinitely.
**Perspective 9:** The exec tool allows execution of arbitrary commands which could include loading model files from untrusted sources. While there are security controls (safeBins, approvals), the system doesn't specifically protect against loading poisoned model weights through command execution.
**Perspective 10:** The exec tool allows shell command execution with multiple host options (sandbox, gateway, node) and elevated privileges. Attackers can chain: 1) Use 'host=gateway' to bypass sandbox restrictions, 2) Use 'elevated=true' for privilege escalation, 3) Use 'security=full' to bypass allowlist checks, 4) Combine with 'ask=off' to disable approval prompts. The tool validates scripts for shell variable injection but doesn't prevent command injection via other vectors. When combined with weak sandbox configurations, this creates a multi-step path from limited execution to full host control.
**Perspective 11:** The function `validateScriptFileForShellBleed` reads script files and performs basic validation for shell variable injection, but it doesn't validate cryptographic aspects such as file integrity, digital signatures, or checksums. This could allow malicious scripts to be executed if they pass the basic syntax checks.
**Perspective 12:** The exec tool accepts user-controlled environment variables via the 'env' parameter. These are merged with the base environment and could be used to inject malicious environment variables that affect command execution or leak sensitive information.
**Perspective 13:** The 'workdir' parameter is resolved without proper validation against path traversal attacks. An attacker could specify a workdir like '../../etc' to execute commands in sensitive directories.
**Perspective 14:** The exec tool executes shell commands with environment variables that may contain sensitive data (API keys, credentials). Functions like sanitizeHostBaseEnv attempt to sanitize but there's no guarantee all PII is removed from inherited environment variables.
**Perspective 15:** The exec tool collects command output without proper size limits. The DEFAULT_MAX_OUTPUT and DEFAULT_PENDING_MAX_OUTPUT constants are used but there's no validation that these limits are actually enforced during execution. The runExecProcess function could accumulate unbounded output if the underlying process produces more data than expected.
**Perspective 16:** The exec tool allows background execution with yieldMs/background parameters. An attacker could create a chain of background processes that spawn more processes, potentially leading to a fork bomb scenario. The tool doesn't limit the number of concurrent background processes per session.
**Perspective 17:** The exec tool allows execution of shell commands in sandbox containers without proper validation of container isolation boundaries. The code references sandbox contexts and container workdirs but doesn't enforce strict container isolation or resource limits.
**Perspective 18:** The code resolves sandbox workdir and container workdir paths without proper validation that the host paths are safely contained within the container's intended boundaries. This could allow path traversal or container escape if malicious paths are provided.
**Perspective 19:** The exec tool allows execution of shell commands with elevated privileges (elevated mode) but lacks comprehensive audit logging. SOC 2 requires detailed logging of privileged access and command execution for security monitoring and forensic analysis. The current implementation logs basic info but doesn't capture full command context, user identity, or authorization decisions.
**Perspective 20:** Command execution can produce output containing sensitive data (credentials, PII, PHI, cardholder data), but there's no data classification or handling based on sensitivity. HIPAA and PCI-DSS require classification and appropriate handling of sensitive data, including encryption and access restrictions.
**Perspective 21:** Tool configurations (safeBins, safeBinProfiles, security levels) can be modified without proper change management controls. SOC 2 requires documented change management processes including approval, testing, and rollback capabilities for security configurations.
**Perspective 22:** The exec tool has a default timeout of 1800 seconds (30 minutes), which could allow long-running processes to consume resources indefinitely. This could be exploited for denial-of-service attacks or resource exhaustion.
**Perspective 23:** The exec tool allows background execution with a default yield window that can be up to 120 seconds. This could allow processes to persist longer than intended and potentially evade cleanup mechanisms.
**Perspective 24:** The exec tool uses DEFAULT_MAX_OUTPUT and DEFAULT_PENDING_MAX_OUTPUT constants for output buffering. Large default buffer sizes could be exploited to cause memory exhaustion through command output flooding.
**Perspective 25:** The code imports from '@mariozechner/pi-agent-core' without specifying a version, which could lead to supply chain attacks or breaking changes if a malicious version is published to the registry.
**Perspective 26:** The exec tool executes shell commands without verifying the integrity or provenance of the binaries being executed. While there are safeBinProfiles and trustedSafeBinDirs configurations, there's no cryptographic verification of binary integrity, no SBOM validation, and no artifact signing verification for executables.
**Perspective 27:** When elevated mode is 'full', the exec tool bypasses approval mechanisms (ask = 'off'). This could allow privileged execution without proper authorization checks.
**Perspective 28:** The validateScriptFileForShellBleed function attempts to detect shell variable injection in Python/JS scripts but has incomplete error handling. If the file read fails or parsing errors occur, the function silently returns without throwing an error, potentially allowing dangerous scripts to execute. The function also has size limits (512KB) that could allow larger malicious files to bypass detection.
**Perspective 29:** The assertSandboxPath function is called without proper error handling in validateScriptFileForShellBleed. If the path validation fails, the function silently continues, potentially allowing path traversal attacks or access to files outside the sandbox.
**Perspective 30:** The exec tool supports elevated execution mode but doesn't log the authorization context or who approved the elevated command. When elevatedMode is 'full' and bypassApprovals is true, there's no audit trail of which user/session initiated the privileged command.
**Perspective 31:** When exec commands run in background (yielded=true), the process continues but there's no correlation ID linking the background process to the original session/request. This makes it difficult to trace which background process belongs to which user session.
**Perspective 32:** The validateScriptFileForShellBleed function attempts to detect shell variable injection in Python/JS scripts but uses a regex that only matches uppercase/underscore variables (\$[A-Z_][A-Z0-9_]{1,}). This misses common injection patterns like lowercase variables ($home, $path), numeric variables ($1), or special variables ($@, $*). The function also has size limits (512KB) and only validates the first match, providing incomplete protection.
**Perspective 33:** The exec tool has multiple security layers (security, ask, safeBins, safeBinProfiles) but the default configuration appears to allow execution with minimal restrictions. The code mentions 'safe by default' but the actual enforcement depends on configuration that may not be properly set up. The validation logic for host environment variables (validateHostEnv) is only called when host !== 'sandbox', potentially allowing unsafe env vars in sandbox mode.
**Perspective 34:** The exec tool executes shell commands with environment variables passed from the base environment and user parameters. If the command includes shell variable injection patterns (like $ENV_VAR) in Python/JS scripts, sensitive environment variables could be leaked to child processes or logged in command output. The preflight validation attempts to detect this but only works for simple cases and small files.
**Perspective 35:** The exec tool captures and returns command output which may include sensitive information (secrets, PII, internal data). This output is returned to the agent and could be logged or transmitted through various channels. The tool has max output limits but doesn't filter sensitive content.
**Perspective 36:** The exec tool allows users to request elevated execution with `elevated=true`. When elevated is requested, the host is forced to 'gateway' regardless of configuration. However, there's a bypass path: if `elevatedDefaults?.enabled` is false or `elevatedDefaults.allowed` is false, the code throws an error but includes detailed configuration hints about which gates are failing. An attacker could use this information to reconfigure the system to allow elevated execution. Additionally, the check for `elevatedDefaults?.enabled` and `elevatedDefaults.allowed` could be bypassed if the attacker can modify the configuration or if there's a race condition during configuration updates.
**Perspective 37:** The exec tool applies `defaultPathPrepend` to the environment PATH when host is not 'node'. This could allow an attacker to prepend a directory containing malicious binaries with the same name as safe binaries, leading to execution of unauthorized code. The `safeBins` and `safeBinProfiles` mechanisms might not catch this if the binary name matches an allowed entry but the path differs.
**Perspective 38:** The exec tool handles environment variables including potentially sensitive ones. While there's validation for host env, the code merges user-provided env variables with base environment which could expose sensitive system environment variables to untrusted commands.
**Perspective 39:** The code uses standard string comparison operations (e.g., `===`, `includes()`, `match()`) which are not constant-time. While this is not directly in a cryptographic context, timing attacks could potentially leak information about command validation or script analysis.
**Perspective 40:** The process tool allows listing and interacting with running processes, which could leak information about system state, other users' processes, or sensitive command arguments.
**Perspective 41:** When executing commands in sandbox containers, there are no health checks or monitoring to ensure the container is in a healthy state before or during command execution.
**Perspective 42:** The exec tool uses a DEFAULT_PATH constant and applies path prepending, which could potentially include insecure directories in the PATH environment variable, leading to command injection or binary hijacking.
**Perspective 43:** The processGatewayAllowlist function makes security decisions about command execution but only logs warnings. No structured audit log records which commands were allowed/denied and why.
**Perspective 44:** The exec tool allows background execution with `yieldMs` or `background=true`. Once a process is backgrounded, subsequent interactions via the process tool (list/poll/log/write/kill/clear/remove) don't re-validate the original security/ask policies. An attacker could start a benign process, background it, then use the process tool to execute unauthorized actions within the same session.
**Perspective 45:** The code reads 'PI_BASH_YIELD_MS' environment variable for exec tool configuration. While not a secret, this shows reliance on environment variables for configuration which is a good pattern for secrets management.
**Perspective 46:** Error messages reference specific environment variable names like 'PI_BASH_YIELD_MS', which could help attackers understand the application's configuration structure.
Suggested Fix
Add structured audit logging before and after command execution, capturing: timestamp, user/session identity, command string, workdir, environment variables, security level, approval status, and execution outcome. Store logs in a secure, tamper-evident location.