T09 · Insecure Skill Coding Practices
- Location
monitor.py:130- Finding
Untrusted PID File Can Cause Termination of an Unrelated Process
- Content
View full analysis
Vulnerability Details
File Location:
monitor.py:130-131
Vulnerability Type: Unvalidated process identifier used for process termination
Risk Level: HighVulnerable Code:
python pid = int(_PID_PATH.read_text(encoding="utf-8").strip()) os.kill(pid, signal.SIGKILL)Technical Analysis
stop_monitor()reads a process identifier directly from the project-localdata/monitor.pidfile and sends an unconditionalSIGKILLto that process. The implementation does not verify that:- The PID belongs to a monitor process started by this application.
- The process executable is the expected Python interpreter.
- The process command line references
monitor.py. - The process creation time matches the monitor instance that created the PID file.
- The PID has not been reused by the operating system after the original monitor exited.
Because PID files are ordinary filesystem objects and no restrictive permissions or ownership validation are applied, any local actor or compromised component capable of writing to the project directory can replace the stored PID. A stale PID may also be reassigned naturally by the operating system.
The use of
SIGKILLincreases the impact because the selected process cannot perform cleanup, flush pending data, or reject the termination request.Attack Path
- A local attacker or compromised process obtains write access to
data/monitor.pid. - The attacker identifies the PID of another process running under the same operating-system account.
- The attacker replaces the contents of
data/monitor.pidwith that PID. - The user or Agent invokes
stop_monitor()orrestart_monitor()through the documented interface. - The application reads the attacker-controlled PID and calls
os.kill(pid, signal.SIGKILL). - The unrelated process is immediately terminated.
A similar outcome can occur without an active attacker if the monitor exits without removin ...[truncated 506 chars]
- Remediation
View remediation
Remediation Suggestions
- Store more than a bare PID. Record the PID, process creation time, and a cryptographically random instance identifier.
- Before signaling, verify that the process creation time still matches the recorded value and that its executable and command line correspond to this project's
monitor.py. - Prefer cooperative shutdown through an authenticated local IPC mechanism, process handle, event, pipe, or owner-restricted control socket.
- Send
SIGTERMfirst and wait for a bounded period before considering forced termination. - Create the runtime data directory and PID file with owner-only permissions, such as mode
0700for the directory and0600for the file where supported. - Use an atomic, exclusively acquired lock file to prevent multiple monitor instances and stale-state races.
- If process identity cannot be conclusively verified, refuse to send a signal and report that the PID file is stale or invalid.
