T03 · Remote Payload Retrieval and Execution
- Location
references/execute.md:78- Finding
Privileged Execution of Remotely Retrieved Installer Scripts
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is mostly coherent for managing ToxTunnel, but it can steer an agent into privileged remote installs and persistent services with some unsafe scoping choices.
Install only if you are comfortable with an agent helping configure remote network access and potentially running root/Administrator install commands. Keep execution manual: pin versions, verify any available digest, do not let a mutable README override reviewed instructions, inspect installers before running them, and explicitly decide whether systemd/launchd/SCM persistence should be enabled.
references/execute.md:78Privileged Execution of Remotely Retrieved Installer Scripts
references/execute.md:35Privileged Installation of Packages Without Enforced Independent Integrity Verification
references/execute.md:136Preferred Package Installation Can Enable Persistent Services Without Explicit Persistence Consent
references/execute.md:20Mutable External README Is Granted Precedence Over Audited Installation Instructions
Referenced artifact was not completely inspected
> `scripts/diagnose.sh` checks all four; run it after writing a rules file.
Referenced artifact was not completely inspected
> `scripts/diagnose.sh` checks all four; run it after writing a rules file.
Referenced artifact was not completely inspected
> `scripts/diagnose.sh` checks all four; run it after writing a rules file.
Referenced artifact was not completely inspected
> `scripts/diagnose.sh` checks all four; run it after writing a rules file.
Referenced artifact was not completely inspected
> `scripts/diagnose.sh` checks all four; run it after writing a rules file.
Referenced artifact was not completely inspected
> `scripts/diagnose.sh` checks all four; run it after writing a rules file.
Referenced artifact was not completely inspected
> `scripts/diagnose.sh` checks all four; run it after writing a rules file.
Referenced artifact was not completely inspected
> `scripts/diagnose.sh` checks all four; run it after writing a rules file.
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
user@127.0.0.1 'whoami; uname -s'
# Web (status + large-file integrity):
curl --noproxy '*' -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:13080/
curl --noproxy '*' -s http://127.0.0.1:13080/big.bin | shasum -a 256 # compare to source
# Postgres (real query):
Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.
**Silent-widening bugs (these are the dangerous ones):**
- **Unrecognised keys inside an allow/deny entry.** Only `host` and `ports` are
read; anything else is ignored with no warning.
- **A missing `ports` key**, which the engine reads as **all ports**. Together
with the previous item, a `port: 22` typo (singular) parses as "allow every
port on that host". Confirmed on v0.4.12: the daemon logs `Loaded access rules`
Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.
**Silent-widening bugs (these are the dangerous ones):**
- **Unrecognised keys inside an allow/deny entry.** Only `host` and `ports` are
read; anything else is ignored with no warning.
- **A missing `ports` key**, which the engine reads as **all ports**. Together
with the previous item, a `port: 22` typo (singular) parses as "allow every
port on that host". Confirmed on v0.4.12: the daemon logs `Loaded access rules`
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
service.allow_client_daemon: true.
If the user explicitly wants this path, pin it to a release tag, download it,
let them read it, and only then run it. master is mutable: the | sudo sh
form executes whatever landed on that branch today, as root, unreviewed.
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
service.allow_client_daemon: true.
If the user explicitly wants this path, pin it to a release tag, download it,
let them read it, and only then run it. master is mutable: the | sudo sh
form executes whatever landed on that branch today, as root, unreviewed.
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
service.allow_client_daemon: true.
If the user explicitly wants this path, pin it to a release tag, download it,
let them read it, and only then run it. master is mutable: the | sudo sh
form executes whatever landed on that branch today, as root, unreviewed.
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
user-customized config (only rewrites the freshly seeded server template
when switching to client).
Do not run the `curl … | sudo sh` or `irm … | iex` form on the user's behalf.
#### Unpinned `-latest` aliases (convenience only)
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
user-customized config (only rewrites the freshly seeded server template
when switching to client).
Do not run the `curl ... | sudo sh` or `irm ... | iex` form on the user's behalf.
#### Unpinned `-latest` aliases (convenience only)
This one-liner chains a mutable remote download directly into privileged installation using && sudo, encouraging operators to skip inspection and verification. In a tunneling/VPN skill, compromise would grant an attacker persistent privileged foothold on a machine likely intended for remote access, amplifying the blast radius.
ARCH=x86_64 # or aarch64 (Darwin: arm64 / x86_64)
BASE=https://github.com/agentx-icu/tox-tcp-tunnel/releases/latest/download
wget "$BASE/toxtunnel-Linux-${ARCH}-latest.deb" && sudo dpkg -i "toxtunnel-Linux-${ARCH}-latest.deb"
wget "$BASE/toxtunnel-Linux-${ARCH}-latest.rpm" && sudo rpm -i "toxtunnel-Linux-${ARCH}-latest.rpm"
wget "$BASE/toxtunnel-Darwin-${ARCH}-latest.pkg" && sudo installer -pkg "toxtunnel-Darwin-${ARCH}-latest.pkg" -target /
# Windows: $BASE/toxtunnel-Windows-AMD64-latest.msi (ARM64 variant available), run as Administrator
The RPM example similarly chains download success directly to privileged execution. This reduces operator scrutiny and turns a repository compromise into immediate root-level code execution.
ARCH=x86_64 # or aarch64 (Darwin: arm64 / x86_64) BASE=https://github.com/agentx-icu/tox-tcp-tunnel/releases/latest/download wget "$BASE/toxtunnel-Linux-${ARCH}-latest.deb" && sudo dpkg -i "toxtunnel-Linux-${ARCH}-latest.deb" wget "$BASE/toxtunnel-Linux-${ARCH}-latest.rpm" && sudo rpm -i "toxtunnel-Linux-${ARCH}-latest.rpm" wget "$BASE/toxtunnel-Darwin-${ARCH}-latest.pkg" && sudo installer -pkg "toxtunnel-Darwin-${ARCH}-latest.pkg" -target /
The macOS convenience one-liner chains a mutable download to sudo installer, which executes package scripts as administrator. The chaining pattern makes risky behavior easy to copy-paste without pause or verification.
BASE=https://github.com/agentx-icu/tox-tcp-tunnel/releases/latest/download wget "$BASE/toxtunnel-Linux-${ARCH}-latest.deb" && sudo dpkg -i "toxtunnel-Linux-${ARCH}-latest.deb" wget "$BASE/toxtunnel-Linux-${ARCH}-latest.rpm" && sudo rpm -i "toxtunnel-Linux-${ARCH}-latest.rpm" wget "$BASE/toxtunnel-Darwin-${ARCH}-latest.pkg" && sudo installer -pkg "toxtunnel-Darwin-${ARCH}-latest.pkg" -target /
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
#### Build from source (only if no package fits)
- macOS: `brew install libsodium && cd <project> && cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j$(sysctl -n hw.ncpu) && sudo cp build/toxtunnel /usr/local/bin/`
- Linux (Debian/Ubuntu): `sudo apt install libsodium-dev build-essential cmake && cd <project> && cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j$(nproc) && sudo cp build/toxtunnel /usr/local/bin/`
- Linux (Fedora/RHEL): `sudo dnf install libsodium-devel cmake gcc-c++ && ...`
- Windows: build with MSVC + vcpkg or MSYS2 (see `BUILDING.md`)
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
#### Build from source (only if no package fits)
- macOS: `brew install libsodium && cd <project> && cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j$(sysctl -n hw.ncpu) && sudo cp build/toxtunnel /usr/local/bin/`
- Linux (Debian/Ubuntu): `sudo apt install libsodium-dev build-essential cmake && cd <project> && cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j$(nproc) && sudo cp build/toxtunnel /usr/local/bin/`
- Linux (Fedora/RHEL): `sudo dnf install libsodium-devel cmake gcc-c++ && ...`
- Windows: build with MSVC + vcpkg or MSYS2 (see `BUILDING.md`)
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
#### Build from source (only if no package fits)
- macOS: `brew install libsodium && cd <project> && cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j$(sysctl -n hw.ncpu) && sudo cp build/toxtunnel /usr/local/bin/`
- Linux (Debian/Ubuntu): `sudo apt install libsodium-dev build-essential cmake && cd <project> && cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j$(nproc) && sudo cp build/toxtunnel /usr/local/bin/`
- Linux (Fedora/RHEL): `sudo dnf install libsodium-devel cmake gcc-c++ && ...`
- Windows: build with MSVC + vcpkg or MSYS2 (see `BUILDING.md`)
The skill explicitly instructs the agent to generate, validate, and in Execute/Diagnose modes run shell commands, but it declares no tool restrictions such as allowed-tools or permissions. In an agent environment, that mismatch is dangerous because a user can trigger shell-capable behavior without an explicit capability boundary, increasing the chance of unintended command execution on the host.
The skill includes detailed OS-specific instructions noting that macOS/Linux package installs bootstrap launchd/systemd services automatically. Because the skill also supports Execute mode, these instructions materially increase the risk that an agent causes unintended persistence contrary to user expectations.
3. **Minimum privilege by default.** When generating rules.yaml, only allow the exact host:port combinations needed. Each friend gets their own rule entry with explicit 64-char hex public key.
4. **No friend wildcards.** The `friend` field in rules.yaml must be an exact 64-character hex public key. Never use `*` for friend identity.
5. **OS-aware.** Detect or ask the user's OS and tailor paths, commands, and service management:
- macOS (package): `binary: /usr/local/bin/toxtunnel`; example config at `/usr/local/share/toxtunnel/config.yaml.example`. The pkg postinstall **automatically** seeds `/usr/local/etc/toxtunnel/config.yaml` from the example, installs `com.toxtunnel.daemon.plist` into `/Library/LaunchDaemons/`, and runs `launchctl bootstrap`. The daemon then honours `service.allow_client_daemon` / `service.auto_start` and exits 0 cleanly when gated off.
- Linux (package): `binary: /usr/bin/toxtunnel`, `config: /etc/toxtunnel/config.yaml`, `data: /var/lib/toxtunnel`, service: `toxtunnel.service` (`Type=notify`, `RemainAfterExit=yes`). The postinst seeds the config from the example and runs `systemctl enable --now`. Server installs come up online; client installs idle (`active (exited)`) until the user fills in `client.server_id` and sets `service.allow_client_daemon: true`.
- Windows (package): `binary: C:\Program Files\ToxTunnel\bin\toxtunnel.exe`. **The MSI does NOT auto-register the SCM service** (the WiX patch is shelved in `cmake/Packaging.cmake` until the correct CPack-generated component Id is discovered). Workflow: user runs the MSI, creates `C:\ProgramData\ToxTunnel\config.yaml`, then registers the service explicitly: `& 'C:\Program Files\ToxTunnel\bin\toxtunnel.exe' install-windows-service -c 'C:\ProgramData\ToxTunnel\config.yaml'`, then `sc start ToxTunnel`. The repo's own `scripts/install.ps1` (in the tox-tcp-tunnel repository, not this skill's `scripts/`) does all of this automatically (download → install → seed config → start service) base
...[truncated 25 chars]
The skill documents package behavior that automatically enables and starts a persistent service (systemctl enable --now) during install. In agentic contexts, session persistence is sensitive because installing a package could silently create a long-lived background daemon even though the skill's own policy says not to enable persistence without explicit request.
4. **No friend wildcards.** The `friend` field in rules.yaml must be an exact 64-character hex public key. Never use `*` for friend identity.
5. **OS-aware.** Detect or ask the user's OS and tailor paths, commands, and service management:
- macOS (package): `binary: /usr/local/bin/toxtunnel`; example config at `/usr/local/share/toxtunnel/config.yaml.example`. The pkg postinstall **automatically** seeds `/usr/local/etc/toxtunnel/config.yaml` from the example, installs `com.toxtunnel.daemon.plist` into `/Library/LaunchDaemons/`, and runs `launchctl bootstrap`. The daemon then honours `service.allow_client_daemon` / `service.auto_start` and exits 0 cleanly when gated off.
- Linux (package): `binary: /usr/bin/toxtunnel`, `config: /etc/toxtunnel/config.yaml`, `data: /var/lib/toxtunnel`, service: `toxtunnel.service` (`Type=notify`, `RemainAfterExit=yes`). The postinst seeds the config from the example and runs `systemctl enable --now`. Server installs come up online; client installs idle (`active (exited)`) until the user fills in `client.server_id` and sets `service.allow_client_daemon: true`.
- Windows (package): `binary: C:\Program Files\ToxTunnel\bin\toxtunnel.exe`. **The MSI does NOT auto-register the SCM service** (the WiX patch is shelved in `cmake/Packaging.cmake` until the correct CPack-generated component Id is discovered). Workflow: user runs the MSI, creates `C:\ProgramData\ToxTunnel\config.yaml`, then registers the service explicitly: `& 'C:\Program Files\ToxTunnel\bin\toxtunnel.exe' install-windows-service -c 'C:\ProgramData\ToxTunnel\config.yaml'`, then `sc start ToxTunnel`. The repo's own `scripts/install.ps1` (in the tox-tcp-tunnel repository, not this skill's `scripts/`) does all of this automatically (download → install → seed config → start service) based on `--Mode` — download and review it before running, see General Rule 6. Removal: `uninstall-windows-service`. Upgrading in place (`msiexec /i new.msi /qn`) keeps the config, `data\` and the
...[truncated 25 chars]
No suspicious patterns detected.