GHSA-59fj-m2j6-hcxh: OS Command Injection

Summary In Glances 4.5.5 the --disable-config-exec flag was extended (GHSA-3vwc-qwhc-3mj7) to stop securepopen() from interpreting the shell operators &&, | and > in AMP command values taken from the configuration file. The hardening was not applied to the on-alert action command path, which reads its command lines from the same configuration file. As a result, with --disable-config-exec enabled, a configured alert action that contains > (file redirection), && (chaining) or | (pipe) still has those operators interpreted, allowing arbitrary file write / command chaining at the privilege of the glances process when the alert triggers.

Affected code glances/actions.py (Glances 4.5.5, latest): python ret = securepopen(cmdfull) # line 111 — no allowoperators=, defaults to True By contrast the AMP modules were fixed: python glances/amps/default/init.py:69 self.setresult(securepopen(res, allowoperators=self.allowoperators()).rstrip()) glances/amps/systemv/init.py:60 res = securepopen(self.get('servicecmd'), allowoperators=self.allowoperators())

PoC (benign) glances.conf: ini [cpu] usercritical=1 usercriticalaction=echo MARKER > /tmp/pocmarker Run glances --disable-config-exec and generate CPU load. When the cpu user alert reaches CRITICAL, /tmp/pocmarker is created — i.e. the > operator was interpreted despite --disable-config-exec. The same > in an [amp] command value is correctly not interpreted.

Impact Arbitrary file write (>), command chaining (&&) and pipe (|) from config-defined alert actions, contrary to the guarantee of --disable-config-exec. Trust boundary = the glances configuration file.

Suggested fix Pass allowoperators=not args.disableconfigexec from GlancesActions.run() into securepopen() (GlancesActions already holds args).

Credit Reported via responsible-disclosure incomplete-fix measurement study.