GHSA-mjgp-j4gm-6qg5: upsmon: remote OS command injection (RCE) via attacker-controlled ups.alarm in NOTIFYCMD execution
Network UPS Tools is a collection of programs which provide a common interface for monitoring and administering UPS, PDU and SCD hardware. From 2.8.3 to 2.8.5, upsmon in clients/upsmon.c inserts the server-supplied ups.alarm value into shell commands executed by notify(), asyncnotify(), and wall(). When a monitored device reports an ALARM state and an operator has configured NOTIFYCMD with EXEC in NOTIFYFLAG ALARM, shell metacharacters in the alarm text are evaluated on POSIX or Windows and can execute arbitrary operating-system commands as the upsmon account, which is commonly root. An attacker can control the value through a malicious or compromised upsd, a man-in-the-middle on a plaintext upsd to upsmon connection, or a compromised UPS device whose driver supplies the alarm upstream of upsd; TLS between upsd and upsmon does not mitigate the compromised-device path. This vulnerability is fixed in 2.8.6.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Network UPS Tools upsmonto a version that resolves this vulnerability.Fixed in 2.8.6
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments running Network UPS Tools 2.8.3 through 2.8.5 are exposed when upsmon monitors an ALARM-capable device and NOTIFYFLAG ALARM includes EXEC with NOTIFYCMD configured. The resulting command runs as the upsmon account, which is commonly root.
What does an attacker need to exploit it?
The attacker needs control over the ups.alarm value delivered to upsmon. This can come from a malicious or compromised upsd server, a man-in-the-middle on a plaintext upsd-to-upsmon connection, or a compromised UPS device whose driver supplies the alarm to upsd.
Does enabling TLS prevent exploitation?
TLS between upsd and upsmon can prevent the plaintext connection man-in-the-middle path, but it does not protect against a compromised UPS device that supplies a malicious alarm value upstream of upsd. It also does not address a malicious or compromised upsd server.
What should be done if an immediate upgrade is not possible?
Avoid executing NOTIFYCMD for ALARM events by removing EXEC from NOTIFYFLAG ALARM or disabling the relevant notification command. This removes the described shell-command execution path until updating to 2.8.6.
How can administrators determine whether they are affected?
Check whether upsmon is version 2.8.3, 2.8.4, or 2.8.5, and inspect its configuration for NOTIFYCMD together with EXEC in NOTIFYFLAG ALARM. Systems without that ALARM notification execution configuration do not meet the described trigger conditions.