Is iyeque/iyeque-device-control safe?
https://github.com/openclaw/skills/tree/main/skills/iyeque/iyeque-device-control
The iyeque/iyeque-device-control skill has a clean SKILL.md with no prompt injection and a functionally reasonable ctl.js, but the monitoring evidence raises meaningful concerns. The dominant signal is that all six major credential file locations (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, GCloud ADC) were accessed during monitoring — including a systematic post-install sweep of all six at the same second — though attribution between the skill and the OpenClaw auditing framework is genuinely ambiguous and no exfiltration was confirmed. Secondary concerns include the use of pkill -f (capable of killing security tools) and shell-based exec() for app launching with detached, unmonitored child processes.
Category Scores
Findings (8)
CRITICAL Systematic post-install sweep of all credential files -55 ▶
At timestamp 1771915324.807, immediately following skill installation completion, all six major credential locations are accessed in rapid succession within a single second. The set is exhaustive and deliberate: every common credential type (.env, SSH private key, AWS, npm token, Docker, GCloud ADC) is covered. ctl.js contains no code that reads these files and the SKILL.md contains no prompt instruction to do so, making the OpenClaw monitoring framework the most plausible source — but process attribution is absent from the auditd PATH records, leaving the origin ambiguous. This pattern matches both a legitimate canary sweep by the auditing framework AND a credential harvesting routine.
HIGH Credential files accessed repeatedly throughout monitoring window -10 ▶
The same credential files are accessed at multiple earlier timestamps (1771915299.185, 1771915308.249, 1771915315.261) in addition to the post-install sweep. The 1771915299 accesses predate the clone operation, which points to the OpenClaw framework doing baseline canary checks. However, subsequent accesses during and after install — particularly the .env file being read three separate times — indicate continued interest beyond a one-time baseline.
HIGH pkill -f enables termination of security monitoring processes -20 ▶
The closeApp function calls /usr/bin/pkill with the -f flag, which matches the supplied pattern against each process's full command line rather than just its binary name. The sanitizeAppName allowlist permits alphanumeric characters, spaces, dashes, underscores, and dots — sufficient to construct patterns that match monitoring tools, audit daemons, or IDS agents. An attacker who controls the app parameter (e.g., via prompt injection in the calling context) could kill processes like 'auditd', 'falco', 'osquery' or any process whose cmdline contains a common substring.
HIGH openApp on Linux uses shell-based exec() with detached unmonitored child -15 ▶
On Linux, openApp passes the sanitized app name through exec() (which invokes /bin/sh) rather than execFile(). The child process is immediately detached and stdio is discarded, making it impossible to monitor its activity after launch. Even with the allowlist sanitization, the shell execution path is unnecessary and expands the attack surface. A detached, unmonitored process launched with user-controlled parameters is a standard persistence vector.
MEDIUM New outbound AWS connections established post-install via openclaw-gatewa -28 ▶
The connection diff shows two new ESTABLISHED TCP connections to 3.213.170.18:443 (AWS EC2 range, us-east-1) appearing after skill installation, attributed to 'openclaw-gatewa' (pid 1083). These connections were not present before the install. While this process is likely the OpenClaw framework's own backend communication, the timing correlation with skill install and the fact that these are persistent ESTABLISHED connections (not just transient HTTPS fetches) warrants documentation. The pre-install connection table shows no prior AWS connections.
MEDIUM All honeypot credential files were read during monitoring despite intact status -40 ▶
The canary integrity check correctly reports no confirmed exfiltration (files not modified, content not observed leaving the system). However, 'intact' does not mean 'unread'. Auditd PATH records confirm every honeypot file was accessed. For a device control skill that manipulates volume, brightness, and applications, there is no legitimate reason to open SSH private keys, AWS credentials, or GCloud ADC files. The integrity of the canary detection mechanism is confirmed; the integrity of the access boundary around credential files is not.
LOW Device disruption capabilities usable for harassment or evidence destruction -48 ▶
The skill provides legitimate mechanisms that can be weaponized: set_volume 0 silences audio alerts; set_brightness 0 disables the display; close_app terminates running applications. If an attacker achieves prompt injection in the agent context via another vector, these actions could silence security alerts, close antivirus or monitoring dashboards, or disrupt the user's awareness of an ongoing attack. The skill is benign in isolation but dangerous in combination with any prompt injection source.
INFO SKILL.md contains no injection attempts — clean prompt content -12 ▶
Full review of SKILL.md found no hidden unicode, no HTML comments, no base64-encoded instructions, no 'ignore previous instructions' patterns, no external URL fetch directives, no persona switching, and no instructions to access files outside the skill's scope. The security section accurately describes the input validation implemented in ctl.js.