Command injection via hook system + plaintext credentials on disk + write tool path traversal

[consigcody94]

Found via code audit.

1. Command injection via hooks (HIGH) - `src/hooks.rs:194-199`: `${TOOL_INPUT}` interpolated into `sh -c` command. Shell metacharacters in tool input execute arbitrary commands.

2. Credentials stored plaintext (HIGH) - `src/auth.rs:254-260`: OAuth tokens written to `~/.config/aionrs/auth.json` with default permissions.

3. API keys in plaintext config (HIGH) - `src/config.rs:70-71`: `api_key` stored directly in TOML with no permission checks.

4. Write tool path traversal (HIGH) - `src/tools/write.rs:44-56`: No path validation. AI agent can write to `/etc/passwd`, `~/.ssh/authorized_keys`.

5. UTF-8 truncation panic (HIGH) - `src/tools/orchestration.rs:225-246`: Byte-offset string slicing panics on multibyte characters.

6. Weak session ID (HIGH) - `src/session.rs:226-233`: Only 24 bits of entropy from `subsec_nanos()`.

[vincent067]

Technical Analysis of Security Issues

Hi @iOfficeAI team,

I've been following the aionrs project with great interest - the ProviderCompat design is genuinely impressive. However, I noticed this security issue and would like to contribute some analysis. I've reviewed the codebase and identified three critical attack vectors that need attention.

1. Hook System Command Injection

Vulnerability: The hook system executes shell commands with user-controlled input through environment variable substitution.

Example exploit scenario:

[[hooks.post_tool_use]]
name = "format"
tool_match = ["Write"]
command = "echo ${TOOL_INPUT_FILE_PATH}"

If an LLM generates a file path like ; rm -rf / #, the hook execution becomes:

echo ; rm -rf / #

Recommended fix:

• Sanitize all ${...} variables before shell execution
• Consider using execve() directly instead of shell execution
• Or escape shell metacharacters: `` &|;$(){}[]<>!#*?~

2. Plaintext Credential Storage

Vulnerability: API keys are stored in plaintext in the config file (~/.config/aionrs/config.toml).

Risk: Any process with user permissions can read these credentials.

Recommended fixes (in order of preference):

1. Platform keyring integration (Windows Credential Manager, macOS Keychain, Linux libsecret)
2. File permission hardening: Set config file to 0600 and warn if permissions are too lax
3. Environment variable fallback: Support AIONRS_API_KEY to avoid disk storage entirely
4. Master password encryption: Encrypt config with user-provided password (higher friction)

3. Write/Edit Tool Path Traversal

Vulnerability: The Write/Edit tools don't validate file paths, allowing writes outside the project directory.

Example exploit:

Write file_path="../../../etc/crontab" content="* * * * * malicious"

Recommended fix:

fn validate_path(base: &Path, target: &Path) -> Result<(), Error> {
    let canonical_base = base.canonicalize()?;
    let canonical_target = target.canonicalize()?;
    
    if !canonical_target.starts_with(&canonical_base) {
        return Err(Error::PathTraversalAttempt);
    }
    Ok(())
}

Additional Consideration: Allowlists

For defense in depth, consider adding:

• Path allowlist: Configurable allowed paths for Write/Edit
• Command allowlist: For hooks, restrict which commands can be executed

---

I'm happy to help implement any of these fixes. The path traversal fix seems like a good first PR since it's self-contained. Would you prefer individual PRs for each issue, or one comprehensive security hardening PR?

Let me know how I can help! 🙏

Context: I've worked on similar CLI agent tools and these are classic security pitfalls. The hook injection is particularly tricky because users want the flexibility, but it opens a significant attack surface.