Package: gsad
Version: 25.2.0-2
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-CC: [email protected]
Hello,
As requested by the Debian Security Team, I am filing this publicly. gsad's
logrotate fragment (debian/gsad.logrotate, installed as
/etc/logrotate.d/gsad) has the same defect as the one I am reporting
separately against openvas-scanner. Verified in 25.2.0-2 (unstable); also
present in 24.16.0-1.
/var/log/gvm/gsad.log {
...
postrotate
if [ -s /run/gvm/gsad.pid ]; then kill -1 `cat /run/gvm/gsad.pid`; fi
openvaslogs=`ls /var/log/gvm/gsad.log.*`
if [ -n "$openvaslogs" ]; then
chown _gvm:_gvm $openvaslogs
chmod 640 $openvaslogs
fi
endscript
}
postrotate runs as root (no su directive). chown is called without
-h/--no-dereference, so a symlink matching gsad.log.* that _gvm plants in
the _gvm-owned /var/log/gvm makes root change ownership of the link target
to _gvm (CWE-59). $openvaslogs is also unquoted, so whitespace and leading
"-" in filenames are not handled safely. The result is local privilege
escalation from the _gvm service account to root.
Same reproduction as the openvas-scanner report: a root-owned mode-0600
canary outside /var/log/gvm became _gvm:_gvm 0640 after logrotate ran.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)
Suggested fix:
find /var/log/gvm -maxdepth 1 -type f -name 'gsad.log.*' -exec chown
_gvm:_gvm {} +
or drop the chown/chmod part of postrotate, since "create 640 _gvm _gvm"
already sets ownership on the new log.
Regards,
Ali Ganiyev
[email protected]
