"Rachelbythebay" has clarified the Atop alarm: Turns out it was just a weird little bug, and it's probably already been fixed.
Veteran sysadmin, industry observer and commentator Rachel Kroll, who blogs as rachelbythebay, posted an update about the odd behavior in the atop command, which she warned about on Wednesday.
Atop is a system and process-level resource monitoring tool primarily designed for Linux. It is included in the package repositories of most major Linux distributions, although it is not typically installed by default.
Kroll's follow-up post, titled Problems with the heap, opens with:
Okay, first off, everybody breathe. Everyone is freaking out. This is not the way to do this.
The post goes on to explain the strange behavior Kroll observed in the atop command, which she described as suspicious - likening it to a children's playground built out of dangerously sharp materials. She also explained directly to The Register:
This is one of these things where I personally don't know how to exploit it, and I don't feel like trying to make it happen. That's work.
I've just seen enough cases of stuff like this being blown open, hence the tip to maybe not run it any more. It really is a "very sharp playground."
In summary, there was a bug in atop that allowed unrelated programs to cause the atop command to fail, and to crash in more than one way. This sort of behavior should not occur and typically signals a deeper problem. This kind of unexpected behavior is the stuff of which exploits are made. That doesn't mean this was an actual exploit - there's no evidence of one - but it was a weird little bug, and that's a bad thing.
Alongside the discussion, the maintainer of atop identified an issue related to memory mapping and addressed it by reintroducing a check around the munmap() call yesterday. This check had previously been removed during a cleanup commit that also eliminated other safeguards deemed redundant. Those removals are now under further scrutiny.
It is almost needless to say that there is also now a call to rewrite atop in Rust. It's facetious, but the deeper point is real: the C programming language is full of undefined behavior like this, and finding a safer way to do system programming is the reason that Rust exists at all.
Many commentators are saying that a more proper way to report this sort of possible bug is to formally file a current vulnerability exposure. If so, good news: there is one.
Our sympathies are with Kroll on this. She saw some strange behavior, and lacking the time to fully investigate what was happening, isolate it, and go through the formal process of submitting a fault report, she made a small post on her personal blog saying that something might be wrong. As it happens, her personal blog is widely-read, and she's a respected industry commentator, so the result was a lot of coverage – and concern. Could she have handled it differently? Possibly. Was it better to highlight than do nothing at all? Definitely yes, in our humble opinion.
As it is, she has flagged something that it seems many people had not realized: that atop is not just another top-like-command, like top and htop and btop++ and the rest, some of which come preinstalled. Unlike other "tops", atop has a background component, and even if nothing else is wrong, that generates log files. Atop, for clarity, isn't inherently risky, but if you don't need it, it probably is not something that you should leave turned on just in case.
Bootnote
Credit for the splendid sobriquet of OverDAtop goes to Reg commenter PhilS. How can the world take a possible vulnerability seriously unless it has a catchy nickname? Now all it needs is a logo and a website… ®