Introduction:
Atop mainly reads the system level and process level from the /proc and
/sys directories. However, certain counters might be obtained from other
optional sources, that have to be activated explicitly.
One of these sources is the 'atopgpud' daemon, which permanently gathers
metrics about the utilization of GPUs. It offers a local TCP port to which
atop can connect to retrieve GPU-related counters. These counters are
provided as strings that have to be parsed by atop.
Vulnerability:
The vulnerability is caused by the fact that atop always tries to connect
to the TCP port of 'atopgpud' during initialization. When another local
program has been started (instead of 'atopgpud') that listens to this TCP
port, atop connects to that program. Such program is able then to send
unexpected strings that may lead to parsing failures in atop. These failures
result in heap problems and segmentation faults.
Although no additional information has been received about these heap
problems, the described heap problems were reproduced with a custom
developed test program.
The vulnerability is present since the introduction of 'atopgpud'
in atop 2.4.0.
Solution:
1) Most systems will not explicitly activate the 'atopgpud' daemon.
Therefore, the default behavior of atop is now not to connect to the TCP
port at all. Only when atop is started with the '-k' flag it will try to
connect to the TCP port (in case you know that 'atopgpud' is running).
2) When the '-k' flag is used, the parsing of the strings is improved to
avoid that heap problems can occur.
3) Another optional source for atop might be 'netatop' or 'netatop-bpf'.
Since most systems will not explicitly install/use these sources,
the default
behavior of atop is now not to try to find these sources. Only when
atop is
started with the '-K' flag it will try to find 'netatop' or
'netatop-bpf'.
