Panic averted: It was just a bug in Atop after all

Rachel Kroll has clarified the Atop alarm: Turns out it was just a weird little bug, and it’s probably already been fixed.

The veteran sysadmin, industry observer, and commentator, 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:

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:

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 security exploits are made. That doesn’t necessarily mean this was an actual viable exploitable flaw – there’s no evidence of one, so far – 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 flexibility of the C programming language enables 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.

Tech suppliers await final grade as Trump prepares to flunk Department of Education

Credible nerd says stop using atop, doesn’t say why, everyone panics

Mixing Rust and C in Linux likened to cancer by kernel maintainer

The US government wants developers to stop using C and C++

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 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…