Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might want to stop running atop

rachelbythebay.com

Post reply on HN
Print view View original

101–110 of 155 posts

Re: You might want to stop running atop

#101

Post by devjam »

bigstrat2003 wrote: post #54
plorkyeran wrote: post #17

Earlier quoted context omitted.

Yeah, from a rando this would be just bad vagueposting but Rachel is absolutely someone who could know about a very good reason why we should uninstall atop but be unable to legally say why. I would heed her warning.

I would disagree and still say that this is bad vagueposting. It doesn't matter how reputable the source is: if you say "don't do X" but don't give a reason why, I'm not inclined to listen. Granted I don't use atop anyways, but I don't think a vague blog post - even one from a respected person - is sufficient justification to change what software one uses.

"Don't put your hand in the fire."

Re: You might want to stop running atop

#102

Post by TheDong »

emmelaich wrote: post #94

There's a bunch of interesting recent commits from someone without a public signing key. 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 Could be legit or flawed. Or even fixes for the possib…

1. Unsigned commits is the norm. It's weird to sign git commits. It's weird to upload your gpg key to github. gpg is a nightmare mess.

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.

Re: You might want to stop running atop

#103

Post by TheDong »

wejick wrote: post #100
emmelaich wrote: post #94

There's a bunch of interesting recent commits from someone without a public signing key. 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 Could be legit or flawed. Or even fixes for the possib…

Seems they also are not coming PR. Sus

https://github.com/Atoptool/atop/pull/327 and https://github.com/Atoptool/atop/pull/325 are the PRs with those commits.

Come on.

Re: You might want to stop running atop

#104

Post by AlexClickHouse »

I vaguely remember an old bug in atop, leading to a very unusual consequence.

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.

Re: You might want to stop running atop

#108

Post by TheDong »

No one else seems to have run 'grep system(', so I will:

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.

Re: You might want to stop running atop

#109

Post by jamie0 »

geenat wrote: post #66
protocolture wrote: post #60

Earlier quoted context omitted.

> it's too easy for a dictatorship to force something 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.

I agree it's not good but being realistic: I'd be far less worried about the Australian government stealing/selling customer data, using my servers in a botnet, using my servers to spread malware.. etc. 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

a backdoor would still be a backdoor - even if the "good guys" made it. e.g. Dual_EC_DRBG

Re: You might want to stop running atop

#110

Post by davesmylie »

__turbobrew__ wrote: post #81
d3Xt3r wrote: post #35

Earlier quoted context omitted.

This. Not only that, I don't know of a single person (IRL or online) who used atop, like, ever. In fact, this is the first time I'm even hearing of atop. IIRC, most folks went from top -> htop -> glances -> various btop variants (bashtop, bpytop, btop++ etc)

atop can record to a file and then be replayed in the future. Sometimes a node is so FUBARed that it won’t even emit metrics so atop can sometimes save your ass when it records metrics to disk.

this - I use atop heavily in my fleet for exactly this reason. It's really helped nail some otherwise hard to find root causes.
Post reply on HN