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?
If someone I trust tells me to trust them, I will.
> If someone I trust tells me to trust them, I will.
Huh? When I trust someone, then I trust already and there's no need being told to trust. When I don't trust someone, then I run away when being told to trust. Hell, if someone tells me to trust them, it's a red flag and I drop the trust.
I think there ARE some situations like that, especially when the conversation is public like this. It is pretty easy to think of a lot of good reasons why Rachel can't explain why you need to trust them in this situation. I think saying, "I can't tell you why, please trust me" is a perfectly reasonable thing for someone you trust to say, and I would absolutely listen to them if they say that.
It’s like seeing a road sign that says “danger ahead” and ignoring it because it wasn’t very specific. It’s just.. not a sensible move.
The only question left is "who is going to deliver the quippy one-liner afterwards?"
-- Dr. Ian Malcolm
It does though.
"Don't go down 6th street now" means very different things depending on whether it comes from your buddy, or the bomb squad.
> if you say "don't do X" but don't give a reason why, I'm not inclined to listen.
I hear ya, but, there are sometimes valid reasons people can't say things; and this may well be one of those times. You have every right to do as you like, but it's not necessarily smart now that you've been warned by a respected professional.
(rubber necks directly at the target) WHAT?! Did you just SAY BE DISCRETE BUT ....
My comment condensed an exchange that has happened enough times to be a trope. You try to discretely get someones attention to alert them about an opsec issue, you then whisper and they basically look right at the target and then yell back at you WHY ARE YOU WHISPERING. Nawww, you are on your own now.
I get this a lot with AI now, I tell people what is a current capability and what the curve looks like, I send them a gist of those capabilities and they want to get into some goal post moving debate. I don't engage. I don't care about being right, or being taken seriously. The funny thing is, sometimes when they come back months later with a, "hey it turns out ..." that they want me to say I told you so, or glad you turned around. I literally don't care.
I and the world have suffered so many fools, we have to stop giving them the time of day, for ourselves. They don't realize that they have truly lost when people stop giving them advice or criticism. You know the relationship is over when the other party has zero interest in even engaging in any capacity.
Keep having atop installed until you get absolute proof that it can be exploited, if that's what you want. But the organization whose systems you're administering might not like the fact that you were forewarned and didn't act.
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
Seems that's already started: https://github.com/Atoptool/atop/issues/330
[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.
And yes I'm aware her posts have made it to the top of HN many times in the past. That I've seen, they've all been unhelpful vague-posts like this one.
Maybe she's actually a real expert I should be listening to! But layer upon layer of vague "if you know, you know" do not make that case.
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.
Wait, now that I think about it why are there Fact Checkers for humans and not for AI?
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)
Screenshots summarize this better than I can [0].
- [0] https://github.com/aristocratos/btop?tab=readme-ov-file#scre...
I'm genuinely stunned to figure out there's a whole set of lore of *tops.
I'm not sure I'm being rational from a textbook security perspective, but, it'd take a whole lot of tangible reward to get me off the binaries supplied with the system.
I think it's handy having everything on one screen, but if you know your way around all the individual builtin tools for these, more power to you, no reason to change.
In terms of tangible feature benefits, btop also offers disk I/O stats, network throughput stats, partition usage, and even GPU usage (if your distro compiled it with GPU support).
In terms of "nice" stuff that's non-essential, the overall UI is a lot more user-friendly and in many ways, better (subjectively). Eg there are visual graphs for various metrics, you can filter process names by substring, get detailed stats of a specific process, see the tree view of all the processes, easily show/hide various parts of the UI (eg you can focus solely on the process list if that's the only thing you're interested in).
There are also some distinct advantages the UI offers easier to send specific signals to processes. Eg in btop I can just select SIGSTOP from the menu, whereas in top, I'd need to remember or lookup the numeric equivalent (eg 19 for SIGSTOP).
Other top alternatives also offer similar feature sets. Glances also shows the most recent warning/errors from the system logs), as well as container resource usage which would be handy for some folks.
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.
However, maintainers have a reputational loss risk, just like someone working at a company does, no?
And, of course, GitHub could just replace the file you're served when you download a file from it, and then blame a hacker, a rogue employee, or deny it happened. That is just as well technically possible as any other entity being forced, by their government, to do something, no?
And, of course, if a govt forces you, your reputation is not the thing you're worried about.
I understand your argument, but that seems like it's a different argument from the one I was disagreeing with.
Of course the US government isn't scary if you're in the US, but not everyone is, and governments change.
I'm asking not whether it feels like there's a risk, I'm asking whether, factually speaking, there is a significant enough risk that outweighs all else. Is there?
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.
It has to be 3.
And she knows her stuff, so I'm listening. Luckily we don't use atop.
I'm not saying it isn't 3, but if it is, it seems like there might be more to it than a run-of-the-mill CVE.
Or maybe she doesn't know of a specific vulnerability/backdoor but has some reason to be suspicious there might be.
It might just be that "uninstall" is the simplest one-word advice you can give that will definitely solve the problem.
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.