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)
Some distributions (like Ubuntu) enable that service by default, but some others (like Fedora) don't.
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.
https://rachelbythebay.com/w/2025/03/26/atop/
> user1 does something... and gets user2 to blow up. If you can make that do something useful, then you get user2 to run stuff on your behalf.
I wonder how long/old the problem is in atop?
https://www.atoptool.nl/allnews.php
For anyone interested, here are the latest commits to the GitHub: https://github.com/Atoptool/atop/commits/master/
Edit: I have no knowledge of what this is FYI.
Rewrite it in Rust. /s
[0]: https://www.bodhost.com/kb/how-to-monitor-system-resource-us...
I'd trust her enough to remove a non-essential component like atop basically.
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.
Also tmpname2 could be symlinked to /etc/passwd before it is unlinked..
Yeah, sure, but only if you run atop as root, otherwise it'll just get a "permission denied", and if you can run atop as root with whatever flags you like, you might as well just run 'rm' instead.
It's not a suid binary, so while it's bad code and a smell, I don't think the TOCTOU is a security issue in how it's commonly run (i.e. as an interactive CLI running as your user).
Even w/o an exploit this can be prettier and more secure.
I assume the reason for the incorrect system call is that doing a shell redirect ('>') does actually look prettier though.
Doing the actual right code is definitely less pretty looking IMO: https://github.com/luvit/zlib/blob/8de57bce969eb9dafc1f1f5c2...
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
2. They aren't introducing the bug, those are all unreleased commits, so advice to "uninstall now" for something no distros are shipping would be silly.
3. The diff is trivial, you can read it and figure out if it looks like they're fixing a real exploitable thing. The answer is obviously no.
I agree on that, but note that you're also able to use your existing SSH key for signing commits. https://docs.github.com/en/authentication/managing-commit-si...
Come on.
installed by default in most distributions, e.g. https://packages.debian.org/bookworm/amd64/atop/filelist
She likely can't disclose anything right now.
Is there even a tool to search what is pre-installed in each major distribution(s)?
docker images -q | xargs -I{} -t docker run --rm {} sh -c 'type atop && echo "DANGER!!!"'
I'd be surprised if any large distros shipped it in a stock configuration.
ps. If I said anything wrong, please correct me. I'm a linux newb who jumped from Microsoft's world after getting fed up with their Win11 BS. I'm still learning quite a bit about linux daily.
Welcome to the dark side my friend, it's better here.
> If I said anything wrong, please correct me
Nothing wrong, but if you ever want to see if something is present without actually running it, consider these commands:
ps aux | grep atop # is there a running process named atop?
which atop # is there a runnable command named atop on the PATH?
apt list --installed | grep atop # has apt installed a package named atop?
I am not aware of any that install it by default.
0. https://www.youtube.com/watch?v=rVMn3xk5mcY
Yes, it comes with that music.
IIRC, most folks went from top -> htop -> glances -> various btop variants (bashtop, bpytop, btop++ etc)
I used it when debugging deeper PCIe, CPU, or networking bottlenecks.
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.
We really need to get rid of this mentality. Australia has laws that allow undisclosed, compelled, software updates. Verbally by ministers, but written (confidential) changes can be requested by federal agencies. Many western countries have followed to various degrees. There's no stable trusted government that doesn't want its fingers in your code.
Mainland China, Russia, North Korea, all have proven track records of doing these things and having corporate espionage rat lines: https://www.youtube.com/watch?v=y27B-sKIUHA
https://github.com/xroche/httrack/pull/210/commits/e00339643...
Does a government need to openly act in a specific way for there to be a risk, or is this perceived risk due to a media bias?
I'm genuinely curious if there's a good answer
By the same standard, what are the repercussions for these random fly by night accounts? Just make a new account and try again on an existing project or fork / tweak / rebrand another project.
Steam, VSCode, PyPI, NPM... it would ruin those platforms overnight if they were putting in backdoors themselves.
1. it consumes too much systems resources. So its net-negative impact on the system under observation
2. it's misleading and leads to false diagnoses of situations under review
3. she's under an NDA of some kind related to a CVE or some other high class risk which will come out in due course but she felt a burden to stop people being exposed to risk.
4. I can't count and there are 4, 5, 6 other reasons but these 3 are mine.
Just like Notepad++ back in the day.
For public issues - https://oss-security.openwall.org/wiki/mailing-lists/oss-sec...
For vague-posting about unconfirmed CVEs and zero days - twitter.com and/or mastodon and/or your friend on signal
atop is also normally only ran briefly. It has an optional mode (enabled by default in some, but not all distributions) in which it runs as a service and saves a snapshot of the system state every few seconds; atop can read and show these snapshots when ran briefly.