In Glances 4.5.5 the --disable-config-exec flag was extended (GHSA-3vwc-qwhc-3mj7) to stop secure popen() 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.

glances/actions.py (Glances 4.5.5, latest):

ret = secure popen(cmd full)    # line 111 — no allow operators=, defaults to True

By contrast the AMP modules were fixed:

# glances/amps/default/ init .py:69
self.set result(secure popen(res, allow operators=self.allow operators()).rstrip())
# glances/amps/systemv/ init .py:60
res = secure popen(self.get('service cmd'), allow operators=self.allow operators())

glances.conf:

[cpu]
user critical=1
user critical action=echo MARKER > /tmp/poc marker

Run glances --disable-config-exec and generate CPU load. When the cpu user alert reaches CRITICAL, /tmp/poc marker is created — i.e. the > operator was interpreted despite --disable-config-exec. The same > in an [amp *] command value is correctly not interpreted.

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.

Pass allow operators=not args.disable config exec from GlancesActions.run() into secure popen() (GlancesActions already holds args).

Reported via responsible-disclosure incomplete-fix measurement study.