remote-chrome

Launch, stop, restart, or check the status of a remote Chrome browser service using Xvfb, x11vnc, and noVNC. Use this whenever the user wants to start a head...

This skill appears to implement what it claims (start/stop/status a remote Chrome with VNC/noVNC), but there are a few practical risks and a metadata mismatch you should be aware of: 1) Metadata mismatch: The registry entry declares no required binaries, but the scripts require system packages (Xvfb, x11vnc, noVNC/websockify, Chromium/Chrome, openssl). Install those before running or the start script will fail. The omission in metadata is a sign of sloppy packaging — verify dependencies yourself. 2) VNC password handling: The start script writes the auto-generated VNC password to /tmp/remote-chrome-vnc-password.txt (chmod 600) and the status script constructs a noVNC URL that includes the password in the query string. Embedding the password in URLs risks exposure via browser history, server logs, proxy logs, or Referer headers. Prefer not to expose the service to the public internet; use SSH port forwarding, restrict firewall access, or modify the scripts to avoid placing the password in URLs. 3) Network exposure: The scripts open VNC, noVNC, and Chrome debug ports. Before running, confirm whether Chrome's remote-debugging binds to localhost only (safer) or to all interfaces. If these services are reachable externally, an attacker could access the remote browser and data. Run in a trusted, isolated environment (VM/container) or behind a firewall. 4) Least privilege: Run the scripts as a non-root user. Inspect the scripts before running to ensure no unexpected commands are present (the provided files look benign). If you will expose this on a LAN, consider adding authentication or TLS in front of noVNC/websockify. 5) Quick checks before install: manually verify presence of required binaries (which Xvfb x11vnc websockify chromium openssl), ensure /tmp file lifecycle suits your security posture, and consider editing the script to avoid including passwords in URLs. If you want, I can: (a) list the exact commands the scripts will run to help auditing, (b) suggest a small patch to avoid embedding the password in the URL, or (c) produce a hardened checklist to run this safely (firewall rules, systemd unit, user permissions).

Type: OpenClaw Skill Name: remote-chrome Version: 1.0.0 The skill bundle contains multiple shell injection vulnerabilities in 'start-remote-chrome.sh' and 'status-remote-chrome.sh' because command-line arguments (e.g., --vnc-port, --screen-size) are passed directly into shell commands without sanitization. While the tool's purpose of providing remote VNC access to Chrome is clearly documented and lacks evidence of intentional malice, these vulnerabilities could be exploited via prompt injection to achieve remote code execution on the host system.