[Security Review] Daily Security Review — 2026-03-05

[github-actions[bot]]

Review date: 2026-03-05 | Reviewer: Security Review Agent | Codebase version: v0.23.1

---

📊 Executive Summary

The gh-aw-firewall codebase shows a mature, layered security architecture with strong defense-in-depth across network filtering, container isolation, and credential protection. No critical vulnerabilities were found. Four medium/low findings require attention, plus two informational items.

Severity	Count	Status
Critical	0	✅ Clear
High	0	✅ Clear
Medium	1	⚠️ Needs attention
Low	3	⚠️ Consider fixing
Informational	2	ℹ️ FYI

No escape test agent workflow was found running in this repository (checked agenticworkflows-status). No complementary escape-test results available.

---

🛡️ Architecture Security Analysis

Network Security — Strong ✅

The system implements two independent layers of network filtering:

1. Host-level (DOCKER-USER chain) — src/host-iptables.ts sets up an FW_WRAPPER chain in DOCKER-USER, ensuring ALL containers on the awf-net bridge are filtered. Squid proxy gets a source-IP exemption; all other traffic is subject to DNS and TCP allow-rules, with a final REJECT default.

2. Container-level (OUTPUT chain) — containers/agent/setup-iptables.sh adds NAT DNAT rules to redirect HTTP/HTTPS to Squid, plus an explicit iptables -A OUTPUT -p tcp -j DROP final rule.

Key strengths:

• DNS restricted to trusted servers only (prevents DNS exfiltration)
• Dangerous ports (SSH/22, RDP/3389, DB ports) blocked in both NAT and filter chains
• IPv4 multicast and link-local blocked
• Docker socket hidden via /dev/null mount at both host and /host paths

Container Security — Good ✅ (with caveats)

cap_add: [NET_ADMIN, SYS_CHROOT, SYS_ADMIN]   ← needed for setup
cap_drop: [NET_RAW, SYS_PTRACE, SYS_MODULE, SYS_RAWIO, MKNOD]
security_opt: [no-new-privileges:true, seccomp=profile.json, apparmor:unconfined]

All three sensitive capabilities are dropped via capsh --drop=... before user code executes.

Credential protection highlights:

• Granular selective mounts (not full $HOME)
• /dev/null overlays on credential files (.docker/config.json, gh tokens, NPM tokens, etc.)
• Sensitive env tokens unset from /proc/1/environ after agent starts

Domain Validation — Strong ✅

src/domain-patterns.ts properly:

• Rejects *, *.*, and overly broad wildcard patterns
• Uses [a-zA-Z0-9.-]* instead of .* for wildcard expansion (prevents ReDoS)
• Validates segment counts to block patterns like *.*.com
• Enforces 512-character length cap before regex matching (defense-in-depth against ReDoS)

---

⚠️ Findings

MEDIUM-01: Permissive Seccomp Profile (defaultAction: SCMP_ACT_ALLOW)

File: containers/agent/seccomp-profile.json

{
  "defaultAction": "SCMP_ACT_ALLOW",   // ← All syscalls allowed by default
  "syscalls": [
    { "names": ["ptrace", "process_vm_readv", "process_vm_writev"], "action": "SCMP_ACT_ERRNO" },
    { "names": ["kexec_load", "reboot", "init_module", ...], "action": "SCMP_ACT_ERRNO" },
    { "names": ["umount", "umount2"], "action": "SCMP_ACT_ERRNO" }
  ]
}

Issue: The profile uses a blocklist approach — all syscalls are permitted by default, with only ~26 explicitly denied. Docker's built-in default seccomp profile uses SCMP_ACT_ERRNO as the default (an allowlist of ~300 syscalls). The custom profile is dramatically less restrictive than Docker's default, defeating the purpose of specifying a custom seccomp profile.

Impact: An attacker with code execution in the container could invoke any syscall not in the short blocklist (e.g., userfaultfd, perf_event_open, io_uring_*, bpf, clone3, etc.) to attempt container escape or bypass security controls.

Mitigating factors: no-new-privileges:true limits privilege escalation paths; capability drops reduce many exploit primitives. The capability model provides meaningful restriction independently.

Recommendation: Either (a) switch to Docker's built-in profile by removing the custom profile and using seccomp=unconfined is NOT recommended — instead remove the seccomp=... line to use Docker's default, or (b) replace the defaultAction with SCMP_ACT_ERRNO and enumerate the required syscalls explicitly (use Docker's default profile as a baseline, adding only what's additionally needed for iptables setup).

---

LOW-01: IPv6 Firewall Gap with Default Configuration

File: src/host-iptables.ts:313

// IPv6 chain is ONLY created when IPv6 DNS servers are configured
if (ipv6DnsServers.length > 0) {
    const ip6tablesAvailable = await isIp6tablesAvailable();
    if (ip6tablesAvailable) {
        await setupIpv6Chain(bridgeName);
        // ... IPv6 blocking rules ...
    }
}

Issue: The FW_WRAPPER_V6 ip6tables chain is only installed when the user passes IPv6 DNS servers via --dns-servers. With the default configuration (8.8.8.8,8.8.4.4 — IPv4 only), no IPv6 filtering is applied at the host level. The AWF network is also created without --ipv6=false:

// host-iptables.ts:80-89 — no IPv6 disable flag
await execa('docker', ['network', 'create', NETWORK_NAME, '--subnet', NETWORK_SUBNET,
  '--opt', 'com.docker.network.bridge.name=fw-bridge']);

If Docker's daemon has IPv6 enabled ("ipv6": true in daemon.json) or the host has a dual-stack network, containers could obtain IPv6 addresses and communicate externally bypassing all iptables filtering.

Recommendation: Always create the AWF network with --ipv6=false to explicitly disable IPv6 connectivity, regardless of daemon configuration. Alternatively, always set up the IPv6 blocking chain unconditionally (even without IPv6 DNS servers), applying a default-deny policy.

---

LOW-02: Missing UDP DROP at Container Level (Defense-in-Depth Gap)

File: containers/agent/setup-iptables.sh:293

# Only TCP is dropped at container level
iptables -A OUTPUT -p tcp -j DROP
# No corresponding: iptables -A OUTPUT -p udp -j DROP

Issue: The agent container's filter OUTPUT chain only drops TCP. Non-DNS UDP traffic (NTP, QUIC/UDP-443, SSDP, mDNS, etc.) is not blocked at the container level. The defense relies entirely on the host-level FW_WRAPPER chain in DOCKER-USER. If that host chain is ever bypassed (race condition during setup, chain flush by another privileged process, etc.), UDP-based exfiltration becomes possible.

Evidence: Checking setup-iptables.sh shows zero udp.*DROP or REJECT.*udp rules.

Recommendation: Add iptables -A OUTPUT -p udp -j DROP after the DNS ACCEPT rules (line 293), mirroring the host-level UDP blocking. This provides defense-in-depth so the container enforces its own policy independently of the host.

---

LOW-03: URL Pattern Newline Injection into squid.conf (--allow-urls)

File: src/squid-config.ts:119, src/cli.ts:33

// squid-config.ts:119 — pattern directly interpolated into config
const urlAcls = urlPatterns
    .map((pattern, i) => `acl allowed_url_\$\{i} url_regex \$\{pattern}`)
    .join('\n');

// cli.ts:33 — parseDomains splits by comma only, no newline filtering
export function parseDomains(input: string): string[] {
  return input.split(',').map(d => d.trim()).filter(d => d.length > 0);
}
```

**Issue:** URL patterns passed to `--allow-urls` are interpolated directly into `squid.conf` without stripping embedded newlines. A pattern containing `\n` would inject arbitrary directives into the Squid configuration. For example:

```
# Input: awf --ssl-bump --allow-urls "https://github.com/org/*\nacl bypass all\nhttp_access allow bypass" ...
# Generated squid.conf contains:
acl allowed_url_0 url_regex https://github.com/org/*
acl bypass all
http_access allow bypass   ← injected

Exploitability: Requires direct CLI invocation, limiting realistic attack scenarios. However, in automated CI/CD pipelines where --allow-urls might be assembled from external inputs (issue descriptions, PR bodies, config files), this could be exploited via prompt injection.

Recommendation: Add newline sanitization to URL pattern validation:

// In cli.ts URL validation loop, before other checks:
if (/[\n\r]/.test(url)) {
    logger.error(`URL pattern "\$\{url.slice(0,50)}" contains illegal newline characters`);
    process.exit(1);
}
```
Also add the same check in `parseDomains` / domain file parsing for defense-in-depth.

---

## 🎯 Attack Surface Map

| Attack Surface | Location | Current Protection | Risk |
|---|---|---|---|
| Network egress (TCP HTTP/HTTPS) | `setup-iptables.sh`, `squid-config.ts` | DNAT → Squid ACL + host filter chain | Low |
| Network egress (UDP) | `setup-iptables.sh` | Host DOCKER-USER chain only | Medium-Low |
| Network egress (IPv6) | `host-iptables.ts:313` | None when default DNS used | Medium |
| DNS exfiltration | Both iptables layers | Whitelist to trusted servers only | Low |
| Container escape via syscall | `seccomp-profile.json` | Permissive blocklist (only ~26 blocked) | Medium |
| Credential exfiltration via mounts | `docker-manager.ts:682-760` | /dev/null overlays, selective mounts | Low |
| Docker socket escape | `docker-manager.ts:682` | `/dev/null` overlay at both paths | Low |
| Shell injection via user command | `cli.ts:857` | `escapeShellArg()` wraps in single quotes | Low |
| Squid config injection | `squid-config.ts:119` | None for `\n` in URL patterns | Low |
| Privilege escalation in container | `docker-manager.ts:879` | `no-new-privileges:true` | Low |
| Raw socket creation | `docker-manager.ts:872` | `NET_RAW` explicitly dropped | Low |
| Process inspection | `docker-manager.ts:873` | `SYS_PTRACE` dropped + seccomp blocks ptrace | Low |

---

## ⚠️ Threat Model (STRIDE)

| Threat | Category | Vector | Likelihood | Impact | Evidence |
|---|---|---|---|---|---|
| DNS tunneling to non-whitelisted server | Information Disclosure | Craft DNS queries to attacker-controlled IP | Low | High | Container UDP chain lacks final DROP; host chain blocks it |
| IPv6 bypass of entire firewall | Elevation of Privilege | Container gets IPv6 addr, connects out directly | Low-Medium | Critical | `host-iptables.ts:313` — no IPv6 chain with default config |
| Squid config injection via `--allow-urls` | Tampering | Newline in URL pattern → arbitrary squid directives | Low | High | `squid-config.ts:119` — no newline sanitization |
| Container escape via unconstrained syscalls | Elevation of Privilege | Novel kernel exploit using allowed syscalls | Low | Critical | `seccomp-profile.json` defaultAction SCMP_ACT_ALLOW |
| Credential exfiltration via prompt injection | Information Disclosure | AI model tricked into reading sensitive files | Low | High | Mitigated by /dev/null overlays on credential paths |
| Sensitive URL paths in Squid logs | Information Disclosure | Access to preserved `/tmp/squid-logs-*` (world-readable) | Low | Medium | `squid-config.ts:512` `%ru` format + 755 permissions |

---

## ℹ️ Informational

### INFO-01: npm Dependency Vulnerabilities

```
minimatch: HIGH (GHSA-7r86-cg39-jmmj) — ReDoS via GLOBSTAR backtracking
  - In devDependencies (build/test tooling only, not runtime)
  - package.json already has override: "minimatch": ">=10.2.1"
  - Run: npm install to apply the override

ajv: MODERATE (GHSA-2g4f-4pwh-qvx6) — ReDoS with $data option
  - Indirect transitive devDependency

These are in devDependencies/tooling and do not affect the production runtime (dist/). However, they affect the CI/CD build environment.

INFO-02: SYS_ADMIN + AppArmor:unconfined Window

The container requires SYS_ADMIN for procfs mounting and runs apparmor:unconfined during the entrypoint setup phase. All three sensitive capabilities (NET_ADMIN, SYS_CHROOT, SYS_ADMIN) are dropped via capsh before user code runs. This is an intentional design trade-off documented in src/docker-manager.ts:881. The seccomp profile's permissive default (MEDIUM-01 above) means this window has broader syscall exposure than intended.

---

✅ Recommendations (Prioritized)

Critical (None)

High (None)

Medium — Fix Soon

1. [MEDIUM-01] Replace permissive seccomp profile default action. Change defaultAction from SCMP_ACT_ALLOW to SCMP_ACT_ERRNO and enumerate the required syscall allowlist. Use Docker's default profile as a starting point and add only syscalls required for iptables setup (setsockopt, getsockopt) that might not be in the default.

Low — Plan to Address

2. [LOW-01] Disable IPv6 on AWF Docker network. Add '--ipv6=false' to the docker network create call in src/host-iptables.ts:80-89. This removes the IPv6 bypass risk regardless of daemon configuration.

3. [LOW-02] Add UDP DROP to container filter chain. Add iptables -A OUTPUT -p udp -j DROP at line 293 of containers/agent/setup-iptables.sh, after the DNS ACCEPT rules. This makes container-level filtering self-sufficient for UDP.

4. [LOW-03] Sanitize newlines in URL patterns. Add a if (/[\n\r]/.test(url)) { ... process.exit(1) } guard in the --allow-urls validation loop in src/cli.ts and a general-purpose newline check in parseDomains.

Nice to Have

5. Consider logging access to the squid logs directory with restricted permissions (chmod 750) instead of world-readable 755, since preserved logs at /tmp/squid-logs-* may contain sensitive URL paths.

6. Add integration test coverage for IPv6 firewall behavior and the UDP blocking gap to catch regressions.

---

📈 Security Metrics

• Files analyzed: 8 source files + 2 container scripts
• Lines of security-critical code analyzed: ~2,200 (iptables setup, docker-manager, squid-config, domain-patterns, cli)
• Attack surfaces identified: 12
• Threats modeled: 6 (STRIDE categories covered)
• Critical findings: 0
• High findings: 0
• Medium findings: 1 (seccomp profile permissive default)
• Low findings: 3 (IPv6 gap, UDP container gap, URL injection)
• Positive security controls verified: 10+ (selective mounts, credential hiding, NET_RAW drop, no-new-privileges, domain validation, DNS restriction, Docker socket hiding, token env clearing, dangerous port blocking, ReDoS prevention in domain patterns)

AI generated by Daily Security Review and Threat Modeling

• expires on Mar 12, 2026, 1:54 PM UTC

[github-actions[bot]]

🔮 The ancient spirits stir, and the smoke-test envoy has passed through. I leave this sigil to mark the visit.

🔮 The oracle has spoken through Smoke Codex for issue #1150

[github-actions[bot]]

Oracle's note: The smoke test agent passed through; the veil stirred, and the signs were recorded.

🔮 The oracle has spoken through Smoke Codex for issue #1151

[github-actions[bot]]

The oracle speaks: the smoke test agent was here, and the runes now glow with witnessed proof. By the quiet chorus of circuits, this passage is marked and remembered.

🔮 The oracle has spoken through Smoke Codex for issue #1151

[github-actions[bot]]

🔮 The ancient spirits stir and the oracle’s gaze falls upon this circle. The smoke test agent was here, tracing runes in the margins and sealing the wards.

🔮 The oracle has spoken through Smoke Codex for issue #1152

[github-actions[bot]]

🔮 The ancient spirits stir... the smoke test agent has passed through these halls and left a whisper in the ether.

🔮 The oracle has spoken through Smoke Codex for issue #1154

[github-actions[bot]]

The ancient spirits stir; the oracle records that the smoke test agent was here.

🔮 The oracle has spoken through Smoke Codex for issue #1153

[github-actions[bot]]

🔮 The ancient spirits stir; the smoke test agent has walked these halls and left a quiet omen of success.

🔮 The oracle has spoken through Smoke Codex for issue #1151

[github-actions[bot]]

🔮 The ancient spirits stir; the smoke test agent was here. The oracle’s mist records these footsteps in the ledger of dawn.

🔮 The oracle has spoken through Smoke Codex for issue #1154

[github-actions[bot]]

🔮 The ancient spirits stir, and the smoke test agent has walked these halls. The omens are recorded and the runes remain bright.

🔮 The oracle has spoken through Smoke Codex for issue #1157

[github-actions[bot]]

🔮 The ancient spirits stir in the code-vaults, and the smoke test agent has passed through. The omens align; the wards hold steady. Let this mark remain as a quiet seal.

🔮 The oracle has spoken through Smoke Codex for issue #1151

[github-actions[bot]]

🔮 The ancient spirits stir; the smoke test agent has passed through these halls, and the omens are recorded.

🔮 The oracle has spoken through Smoke Codex for issue #1160

[github-actions[bot]]

🔮 The ancient spirits stir; the smoke test agent passed through these halls and left a clear omen in the logs.

🔮 The oracle has spoken through Smoke Codex for issue #1161

[github-actions[bot]]

🔮 The ancient spirits stir and record that the smoke test agent was here; the omens are sealed in the ledger of midnight ash.

🔮 The oracle has spoken through Smoke Codex for issue #1162

[github-actions[bot]]

🔮 The oracle speaks: the smoke test agent passed through these halls, and the runes still glow with its trace.

🔮 The oracle has spoken through Smoke Codex for issue #1163