Skip to content

fix(OVERPRIVILEGED_TOOL): flag shell:* namespace wildcard (silent gate bypass)#52

Open
dmchaledev wants to merge 1 commit into
mainfrom
claude/amazing-franklin-s7gozc
Open

fix(OVERPRIVILEGED_TOOL): flag shell:* namespace wildcard (silent gate bypass)#52
dmchaledev wants to merge 1 commit into
mainfrom
claude/amazing-franklin-s7gozc

Conversation

@dmchaledev

Copy link
Copy Markdown
Contributor

Summary

OVERPRIVILEGED_TOOL matches dangerous permissions by exact string (DANGEROUS_PERMISSIONS = ['filesystem:write', 'network:*', 'shell:exec']). Because of this, a tool granted shell:* — a strict superset of shell:exec, i.e. full arbitrary command execution on the host — produces zero findings and PASSES the gate, while the identical tool with shell:exec is correctly flagged HIGH.

This is the "silently passes on a real risk" false-negative class: the more-permissive form of the single most dangerous permission slips through the gate.

Repro (built CLI at current main)

// shellstar.json — authenticated, TLS, rate-limited; only issue is the tool perm
{ "transport": { "url": "https://x", "tls": true,
    "auth": { "token": "abcdefghijklmnopqrstuvwxyz0123456789" } },
  "rateLimit": { "enabled": true },
  "tools": [ { "name": "runner", "permissions": ["shell:*"] } ] }
$ node dist/cli.js shellstar.json --format=table
Found 0 finding(s): 0 critical, 0 high, 0 medium, 0 low
PASSED                       # <-- full shell wildcard, gate is green

Characterizing the gap across the dangerous namespaces:

permission before why
shell:exec OVERPRIVILEGED_TOOL listed explicitly
shell:* (none) superset of shell:exec, unflagged
network:* OVERPRIVILEGED_TOOL wildcard listed explicitly
filesystem:* UNRESTRICTED_FILE_ACCESS covered by dedicated rule

So shell:* is the sole dangerous namespace whose wildcard was uncovered.

Fix

OVERPRIVILEGED_TOOL now treats a dangerous namespace's wildcard (ns:*) as at least as dangerous as its specific dangerous permission — a wildcard grants everything the specific permission does. To avoid double-counting the same issue (the codebase already takes this care for MISSING_TLS/INSECURE_TRANSPORT), wildcards owned by a dedicated rule (filesystem:*UNRESTRICTED_FILE_ACCESS) are excluded; network:* stays explicitly listed.

$ node dist/cli.js shellstar.json --format=table
HIGH | OVERPRIVILEGED_TOOL | Tool Has Dangerous Permissions
Found 1 finding(s): 0 critical, 1 high, 0 medium, 0 low

Tests

Added to OVERPRIVILEGED_TOOL rule in scanner.test.ts:

  • shell:* → fires HIGH (evidence names shell:*)
  • filesystem:* → does not double-count (still owned by UNRESTRICTED_FILE_ACCESS)
  • benign logging:* wildcard → does not fire

Full suite: 121 passed. Build + lint clean. No regression on the bundled examples/vulnerable-config.json (its filesystem:* tool still reports only UNRESTRICTED_FILE_ACCESS) or examples/secure-config.json (still passes clean).

🤖 Generated with Claude Code

https://claude.ai/code/session_01CgJhQmgsdSR6CguK51tv2B


Generated by Claude Code

A tool granted `shell:*` — a strict superset of `shell:exec`, i.e. full
arbitrary command execution on the host — previously produced zero findings
and passed the security gate, while the identical tool with `shell:exec` was
correctly flagged HIGH. The rule matched dangerous permissions by exact string,
so the more-permissive wildcard slipped through.

OVERPRIVILEGED_TOOL now treats a dangerous namespace's wildcard (`ns:*`) as at
least as dangerous as its specific dangerous permission. Wildcards owned by a
dedicated rule (`filesystem:*` → UNRESTRICTED_FILE_ACCESS) are excluded to avoid
double-counting; `network:*` remains explicitly listed.

Adds tests for shell:* (fires), filesystem:* (no double-count), and a benign
namespace wildcard (does not fire).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CgJhQmgsdSR6CguK51tv2B
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants