T09 · Insecure Skill Coding Practices
- Location
scripts/smoke_detector.py:56- Finding
Disabled TLS Verification Exposes the Dirigera Bearer Token and Sensor Data Integrity
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill does what it claims, but it handles a home-automation bearer token insecurely enough that users should review it before installing.
Install only if you are comfortable with a cron-based local alarm that reads a Dirigera token from disk. Before using it unattended, fix TLS verification or certificate pinning for the hub, protect the token file with restrictive permissions, consider rotating any token previously used this way, and replace the predictable /tmp audio file with a secure temporary file.
scripts/smoke_detector.py:56Disabled TLS Verification Exposes the Dirigera Bearer Token and Sensor Data Integrity
The skill documentation describes capabilities that include reading tokens from disk, writing state files, querying a networked hub, and invoking local shell-accessible utilities, but it does not declare any explicit tool scope or permissions boundary. In an agent ecosystem, missing scope declarations increases the chance of over-broad execution, unintended access to sensitive files or network resources, and unsafe invocation beyond what users expect from a smoke-alert skill.
The skill intentionally enters a continuous alert loop and repeats audio every 5 seconds until sensor readings normalize, but the description does not prominently warn users about this persistent behavior. That omission can create safety and operational issues such as nuisance alarms, inability to silence alerts easily, disruption during false positives, or user habituation that undermines trust in emergency notifications.
The documentation says the detector 'Queries sensor every 5 minutes,' which matches the manifest, but this file's main() performs one sensor check and exits unless danger is detected. During danger, the code loops every 5 seconds (ALERT_INTERVAL = 5) rather than every 5 minutes, so the documented periodic behavior is contradicted by the actual implementation.
The skill's purpose is detecting dangerous air readings from a Dirigera sensor and issuing alerts, but the implementation does so by spawning local binaries (afplay, say, and ffmpeg). Launching arbitrary system executables is a broader capability than the sensor-monitoring purpose itself and is not justified by the manifest description beyond simply 'broadcasts emergency alert on Mac speaker.'
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
# Play alert sound
def play_alert():
try:
subprocess.run(['afplay', ALERT_SOUND_PATH], timeout=15, check=True)
return True
except:
return False
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
print("Generating alert sound...")
try:
aiff = "/tmp/alert.aiff"
subprocess.run(['say', '-v', 'Samantha', '-o', aiff,
"Attention! Abnormal smoke level detected."],
check=True, capture_output=True)
subprocess.run(['ffmpeg', '-y', '-i', aiff, '-ar', '44100',
The code uses a predictable temporary file path (/tmp/alert.aiff) and then feeds it to ffmpeg. On a multi-user system, an attacker could pre-create or swap that path via symlink/hardlink attacks, potentially causing overwrites or unintended file access under the privileges of the skill process.
subprocess.run(['say', '-v', 'Samantha', '-o', aiff,
"Attention! Abnormal smoke level detected."],
check=True, capture_output=True)
subprocess.run(['ffmpeg', '-y', '-i', aiff, '-ar', '44100',
'-ac', '2', '-b:a', '192k', ALERT_SOUND_PATH],
check=True, capture_output=True)
os.remove(aiff)
The manifest describes a detector that 'queries Dirigera air sensor every 5 minutes,' implying ongoing periodic monitoring as part of the skill. In this file, main() performs a single sensor read and exits when air is normal; there is no built-in 5-minute polling loop, so the claimed monitoring behavior is not actually implemented here.
The skill relies on a stored Dirigera authentication token and performs automatic polling of a local hub, but the documentation does not warn users about the sensitivity of that token or the security implications of unattended network access. If the token file is exposed or permissions are weak, an attacker or another local process could reuse it to query or interact with the home automation environment.
No suspicious patterns detected.