Credible nerd says stop using atop, doesn't say why, everyone panics Veteran sysadmin and tech blogger Rachel Kroll posted a cryptic warning yesterday about a popular Linux system monitoring tool. Maybe it's better to be safe than sorry. The post is titled: "You might want to stop running atop." No details, no context – just a few paragraphs that have set off alarm bells in corners of the Linux …
This post has been deleted by its author
Kroll is a serious security professional who knows what she's talking about as a rule.
It's not looking that way to me from the stuff I have been reading. It looks like she has flushed any reputation she may have had down the pan.
Perhaps this event will be dismissed as 'just a glitch' but I am not so sure.
There's also been a lot of crying wolf recently, like the one which claimed to be "unauthenticated RCE against all GNU/Linux systems" and then turned out to be just CUPS. Or the vague announcement of "probably the worst curl security flaw in a long time" which also turned out to be specific to SOCKS5.
Which is why (a) some skepticism is valid, and (b) the personal reputation of the reporter matters more than anything.
However, we are talking about open source, so we can expect things to be more openly reported.
Also, assuming contractual obligations etc. it is still very easy for someone to let sufficient information out for an independent security tester to look at things…
"It may also be that Kroll is unable to share details due to contractual obligations."
Forget contractual obligations, it's irresponsible to share info until a fix has been released (and had time to bed in) - unless it is being actively exploited. And even if it's being actively exploited, you wouldn't want to point at the hole lest other bad guys create an exploit against it.
So the assessment is, right now, it's reasonable to assume there is an actively exploited hole with no fix available.
She could have given something vaguely in the region of a reason.
"at least ensure unprivileged users can't run it" vs "unless the machine has no networking capability" vs "have disk quota active"
Not an exploit. Not even a pointer to where to inspect the code. Just an indication of the class of issue.
> Was finding it a bit of a head-scratcher
I really did try to clearly spell it out!
«
Atop is slightly different, and we suspect that is critical here. While most top-style programs are live tools that show resource usage right now, atop also has a component that can run in the background…
»
atop is hardly an essential tool. You do not need it running.
If your distro includes it, it would be pragmatic to remove it until we know what's up. Chances are good that you'll not notice it's gone.
If your distro runs it automatically, WHY? It's non-essential, and so a bad security practice almost by definition. Perhaps it's time to find another distribution?
There is no issue.
https://rachelbythebay.com/w/2025/03/26/atop/
- "Okay, first off, everybody breathe. Everyone is freaking out. This is not the way to do this."
'Security' expert doesn't find security issue. Writes scary post. Is confused about why people take them seriously. Remonstrates people who trust them for actually trusting them.
atop is an excellent tool for posthoc debugging of resource issues on a given machine. it's been invaluable in my job to root cause overlayfs performance regressions, IO saturation issues, process termination issues, and a myriad of other things. We'll continue using it until there's actually a security issue, and if there is one we'll do our due diligence on how to mitigate before we rewrite our own atop.
I may need help with my reading comprehension too. I'd appreciate any information about how I've misunderstood the post.
Panicking is useless so stop.
I will now attempt to use a very clumsy analogy involving child endangerment that doesn't really make a whole lot of sense but whatever. (The phrase 'sharpest materials' really boggles my mind. As far as I can tell, sharpness is a property of edges rather than materials.)
All I did was warn people about the place without specifically discussing the risks involved leading to people imagining what kinds of horrible, awful things could be going on to cause me to issue such a nondescript warning.
This is a bad analogy because I didn't go into details. (I did for the analogy, but not for the actual thing I did. A better analogy would have omitted the last two sentences of the first paragraph of the analogy.) I wanted people to stop using atop before adversaries could determine a means of exploiting the thing I found.
I don't know how to exploit the thing I found, but I'm going to mention that overflow attacks were really bad thirty years ago and try to induce more panic.
Here are some pictures of terminals that I made showing things and I'm not going to state whether or not this has actually occurred, but it sure is panic-inducing!
I don't know what I'm talking about but maybe there's danger here?
I'm going to refer to my pictures again and still not state whether they demonstrate something that has actually happened or something that may happen.
Scaremongering!
I was right, y'all are dicks, stfu.
I just ran a quick automated check on a number of platforms by running "command -v atop", and none of them showed up as having atop installed.
The list included: Debian, Ubuntu, Raspberry Pi, Alma (Red Hat clone), Suse, Alpine, OpenSuse, Open BSD, and Free BSD.
I suspect that if atop is present on any mainstream Linux or BSD distro, then either the use installed it explicitly, or it was pulled in as part of something else (I don't have any suggestions on the latter).
If anyone did install this optional package, then it's probably not a big deal to remove it.
You didn't check Solaris? A pity, but I've done it for you. On there, atop actually installs itself using root anytime an operator uses su, and then, as the lady mentions, behaves like a tool for anyone whose login is "user2".
[Article author here]
> You didn't check Solaris? A pity, but I've done it for you.
While I think that I see what you are doing here, and I smiled at the joke -- I am taking it as a gag, and I hope it was meant as one -- the trouble is that a lot of people in this business are not going to get that kind of gag. IT -- and arguably especially infosec -- are areas where people on the Asperger's spectrum can thrive and excel, and they ("we", possibly?) often miss sly humour like this.
Secondly, people who mainly work with computers not other humans can get and keep jobs even when they do not speak the language in which the company operates. I have personally met many people working in Czechia whose English was not great, and who often badly misinterpreted things one native might say to another native speaker.
I don't condemn it. My Czech is terrible and I can only do a sort of broken pidgin, and it took me 9 years of hard work to attain that level. In comparison, I can communicate in broken pidgin German as well, but that took 3 *days* of self-study when I was 20 years old.
3 days -- no hyperbole -- versus 9 years. Not exaggerating.
People with English not much better than my level of German or Czech sometimes get jobs in this business, and those of us communicating in it for a living need to bear that in mind.
It's not a crime to be bad in a language other than your native one. I am really awful in 6 foreign languages, and you know what? Everyone I've ever met is delighted that I even try.
(OK, except in Paris, but that's Paris for you. The rest of France is fine. It's just the Parisians.)
I checked if I had it installed even before I knew how it behaved. I guessed it was a process monitor of sorts. It was not installed. Then I continued to read the article and subsequently comments. At this point I discovered it is unique amongst process monitors in that it runs in the background and writes log entries as root by default. That to me sounds like the sort of tool to use for troubleshooting and put it away when done. I imagine it may have options for verbosity of logs, running as a lower privileged user, maybe some other neat features. I need to try and remember this one if I have the need. As usual, I would probably RTFM before cutting it loose on a system.
I say good call on the warning. It could have easily been installed and forgotten. Also some OSes may have "helpfully" included it as a standard package.
> As usual, I would probably RTFM
Good for you. (And thank you for the comments.)
You are one in a million. For nearly 5 years my day job was to _write_ the manuals, and I can tell you, as a generalisation, _nobody_ ever RTFMs first.
It is very disheartening to work hard for weeks on a chapter of something that you know will only ever be read by people because they got in a mess and who don't want to be reading it.
RTFM is almost as old as computers themselves, and it applies to technologies older than computers, even if the acronym wasn't commonly used then. In the 21st Century it boggles the mind how few people RTFM _before_ they use some technical widget, despite the serious harm that approach can cause themselves and others. Somehow "human nature" falls short as an explanation. Does anyone know of any credible studies regarding this phenomenon?
Of course, with too many apps devoid of a manual (I'm looking at you, smartphones), the users cannot be blamed.
The problem isn't that it "writes log entries as root by default" (anyone can write system log entries without being root); the problem is that it (a) runs as root, and (b) someone has been sloppy about munmap'ping null pointers. This shouldn't really be a problem, but the concern is that another program, which is not running as root, might somehow be able to take advantage of this, and get atop to run something on its behalf, in which case non-root program #2 owns the box.
The moral is that if you've got something you don't know about running in the background, and that program is running as root, and you have concerns about the code quality, then you should stop running that program. Seems fair, and RTFM doesn't really help in this case.
Oh, wait. It's just occurred to me that every time I run Task Manager I see hundreds of these things. Damn.
It's much like network traffic graphs, though.... 99% of the time it's a "useless drag on performance", but that remaining 1% of the time you need it to have been running already for days to months so you can look back at "what happened at $time?" to see where things went wrong. Installing it or running it after the fact does you NO good at all because it wasn't running and collecting data when $event happened.
Unless you've got a time machine in your pocket.
