I’m actually surprised I didn’t have it installed, what with all the packages I check out just through sheer curiosity. Thanks Rachel! I’ll avoid it in the future.
I stopped using atop when I found it installs several hooks which automatically run code as root and deposit files around the filesystem, including a "power management" hook.
There's a lot of speculation about why, with the answer almost certainly security / exploitable (or backdoor), and I'll just throw an extra little tidbit in:
atop seems to run persistently as root, which may be the reason for preventing it from running/uninstalling.
the netatop part of atop installs a persistent kernel module, netatop.ko, as part of its installation. The module hooks netfilter to be able to monitor all traffic.
If there's an exploitable flaw in the kernel module, this would be a max-severity CVE.
netatop _also_ runs a persistent daemon, netatopd, which I believe from inspecting the source runs as root.
The article's language about uninstalling it kinda sorta makes you think one of these three parts is in some way exploitable or backdoored — any which way it's a privileged process, and one that's monitoring network traffic.
(I'm not sure if netatop is installed by default on systems when you install atop, per czk's comment below)
Repositories controlled by accounts based in mainland China and Russia are always a risk- it's too easy for a dictatorship to force something to happen even if the authors themselves are trying to act in good faith.
Is there a mechanism where this sort of advice can flow through security teams to everyone (assuming it is about security) without dropping the details. How are zero days dealt with?
Linux newbie here. Jumped into the Linux world after getting tired of Microsoft's BS with Win 11. Running Linux mint on my laptop and desktop. Looks like 'atop' is not installed by default, but regular 'top'. Anyone know which distros I should be worried about that have it? Also I have been dabbling with proxmox, I checked and looks like 'top' is the default there too.
There's a bunch of interesting recent commits from someone without a public signing key.
Removed excess checks before free()
Fixed possible wrong result bit shifting on 64bit after left op type overflow
Fixed possible wrong result bit shifting on 64bit after left operand type overflow
Fixed possible access out-of-bounds items array better check index before using
Could be legit or flawed. Or even fixes for the possible flaw.
At a previous gig, atop was running fleet-wide (> 1k servers) as sort of a resource monitoring tool of last resort, in a similar way as is described in this article[0]. I left a few years ago, but if memory serves, this thing was baked into base-image Puppet configs, and proved itself handy in past investigations of hard-to-find problems. If this turns to be real threat, I wouldn't be surprised if the blast radius for this is substantial.
I vaguely remember an old bug in atop, leading to a very unusual consequence.
Atop will do an invalid memory write and crash with a segfault. But this writing is performed on a memory page mapped to a hardware timer. Despite not being able to write into that page, just touching it somehow changes how this hardware timer works. Then, the OS detects that this timer is inaccurate and switches to a different clock source (which you can see in /sys/devices/system/clocksource/clocksource0/current_clocksource). As a result, every call to clock_gettime becomes slower, and the system becomes slower as a whole until it restarts.
In short, a segfault in atop leads to the whole system's performance degradation. But this was found around maybe 7 years ago.
> system ("gunzip -c %s > %s", tmpname1, tmpname2")
tmpname2 is hardcoded as "/tmp/atopwrkXXXXXX", so that's fine. tmpname1 is '$irawname.gz'. '$irawname' is set by the '-r' flag.
So, presumably if you can get the rest of the code to play nice and get you there, you can escalate from having shell access to run atop, to having shell access. Oh, I guess that's nothing.
Anyway, still a really bad use of system + user-controlled input, don't do that.
Whoops, you're not connected to Mailchimp. You need to enter a valid Mailchimp API key.
Our site uses cookies. Learn more about our use of cookies: cookie policyACCEPTREJECT
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
24 Comments
jaffa2
enigmatic? Anyone know why
desktopninja
btop++
slicktux
Ominous, I’ll heed the warning!
jofzar
This screams NDA/disclosure but things are so mega super fucked that they feel obligated to pre warn as early as possible.
I wonder how long/old the problem is in atop?
alsetmusic
I’m actually surprised I didn’t have it installed, what with all the packages I check out just through sheer curiosity. Thanks Rachel! I’ll avoid it in the future.
Hello71
I stopped using atop when I found it installs several hooks which automatically run code as root and deposit files around the filesystem, including a "power management" hook.
dgacmu
There's a lot of speculation about why, with the answer almost certainly security / exploitable (or backdoor), and I'll just throw an extra little tidbit in:
atop seems to run persistently as root, which may be the reason for preventing it from running/uninstalling.
the netatop part of atop installs a persistent kernel module, netatop.ko, as part of its installation. The module hooks netfilter to be able to monitor all traffic.
If there's an exploitable flaw in the kernel module, this would be a max-severity CVE.
netatop _also_ runs a persistent daemon, netatopd, which I believe from inspecting the source runs as root.
The article's language about uninstalling it kinda sorta makes you think one of these three parts is in some way exploitable or backdoored — any which way it's a privileged process, and one that's monitoring network traffic.
(I'm not sure if netatop is installed by default on systems when you install atop, per czk's comment below)
geenat
Probably a backdoor.
Repositories controlled by accounts based in mainland China and Russia are always a risk- it's too easy for a dictatorship to force something to happen even if the authors themselves are trying to act in good faith.
XZ, Swoole… examples off the top of my head.
bitbasher
Pure speculation; but it sounds to me like she was doing some sysadmin triage and possibly stumbled onto a backdoor/exfiltration through atop.
She likely can't disclose anything right now.
imoreno
Luckily I use a much better *top, btop.
keyle
Is atop included in any distributions?
Is there even a tool to search what is pre-installed in each major distribution(s)?
xyst
[flagged]
nextts
Is there a mechanism where this sort of advice can flow through security teams to everyone (assuming it is about security) without dropping the details. How are zero days dealt with?
amiga386
[flagged]
vanc_cefepime
Linux newbie here. Jumped into the Linux world after getting tired of Microsoft's BS with Win 11. Running Linux mint on my laptop and desktop. Looks like 'atop' is not installed by default, but regular 'top'. Anyone know which distros I should be worried about that have it? Also I have been dabbling with proxmox, I checked and looks like 'top' is the default there too.
zertrin
Seems it's currently experiencing the HN hug of death (not responding for me), here's an archived version https://archive.is/MvNSk
justinator
>My life as a mercenary sysadmin can be interesting
Debatable.
teekert
I recently had a course from the author of atop. Seemed like a straight up FOSS friendly guy, I’ll forward him this page.
LorenDB
For openSUSE users: `sudo zypper al atop` will prevent atop from being installed for any reason, as long as it's uninstalled before you add the lock.
rdtsc
It's Rachel. If she says to remove it, I'll remove it. I see people are suspicious, but I think I'll trust someone like her at least once to do this.
emmelaich
There's a bunch of interesting recent commits from someone without a public signing key.
Could be legit or flawed. Or even fixes for the possible flaw.
spudlyo
At a previous gig, atop was running fleet-wide (> 1k servers) as sort of a resource monitoring tool of last resort, in a similar way as is described in this article[0]. I left a few years ago, but if memory serves, this thing was baked into base-image Puppet configs, and proved itself handy in past investigations of hard-to-find problems. If this turns to be real threat, I wouldn't be surprised if the blast radius for this is substantial.
[0]: https://www.bodhost.com/kb/how-to-monitor-system-resource-us…
AlexClickHouse
I vaguely remember an old bug in atop, leading to a very unusual consequence.
Atop will do an invalid memory write and crash with a segfault. But this writing is performed on a memory page mapped to a hardware timer. Despite not being able to write into that page, just touching it somehow changes how this hardware timer works. Then, the OS detects that this timer is inaccurate and switches to a different clock source (which you can see in /sys/devices/system/clocksource/clocksource0/current_clocksource). As a result, every call to clock_gettime becomes slower, and the system becomes slower as a whole until it restarts.
In short, a segfault in atop leads to the whole system's performance degradation. But this was found around maybe 7 years ago.
TheDong
No one else seems to have run 'grep system(', so I will:
https://github.com/Atoptool/atop/blob/037a6d3e4ace6c7be6c5dc…
> system ("gunzip -c %s > %s", tmpname1, tmpname2")
tmpname2 is hardcoded as "/tmp/atopwrkXXXXXX", so that's fine. tmpname1 is '$irawname.gz'. '$irawname' is set by the '-r' flag.
So, presumably if you can get the rest of the code to play nice and get you there, you can escalate from having shell access to run atop, to having shell access. Oh, I guess that's nothing.
Anyway, still a really bad use of system + user-controlled input, don't do that.