[ClusterLabs Developers] heads-up: procps-ng (notably "ps" tool) as a DoS vector
jpokorny at redhat.com
Mon May 21 15:41:34 UTC 2018
Hello (intentionally primarily) cluster stack development forces,
I came around http://www.openwall.com/lists/oss-security/2018/05/17/1
that seems to indicate it is fairly trivial for an unprivileged user
on an unpatched and non-hardened Linux system using procps-ng as it's
primary package for process listing utilities to block "ps" invocation,
amongst other nasty findings.
I hope it's quite needless to state why this is of importance for
HA cluster users -- stock resource agents often rely on process
listing facilitated with said tool. Fortunately, query-by-PID
looks affected only infinitesimally. Some agents, however, do
exercise full breadth search with later filtering per occurrences
of some string patterns, which is, to some extent, a broken approach
even without that security advisory in the picture (see also ,
all basically amounts to weak, fragile grip on processes, at least
when portability is important). Note that not using "ps" directly
doesn't imply anything, as libprocps shipped with procps-ng can be
used through language bindings under the hood.
So my call is that it'd be wise to revisit usage of ps-like
commands in the agents, in order to keep the surface possibly
affecting run of the resources as small as possible. Opposite
approach, explicit claim that any reliability of the cluster
stack is void when arbitrarily locked-down external user happens
to have a login access to the machine, would also be valid
("no on-host privilege separation is the safest one"), but then
why to bother with ACLs in pacemaker, etc.
Note that it is currently unknown whether only agents'
implementations are hit, as pacemaker itself does some /proc
traversal, though not with the help of libprocps, but on its own.
It looks that at least a negligible race condition may be fixed
on kernel's side (CVE-2018-1121) and pacemaker would directly
benefit from that, but that's just a drop in the ocean compared
to pre-existing /proc handling issues.
It's likewise unkown to what extent other systems and other process
listing utilities are affected.
 parenthesised part of
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Developers