5 ms·
Atop 2.11 heap problems
- zitterbewegung 2y agoIs it just me or does this seem like a bad design where a TCP port is exposed to share information?
- marginalia_nu 2y agoAs long as you bind to localhost it's fine in theory. Though any network code still needs to be rigorously hardened.
- echoangle 2y ago> As long as you bind to localhost it's fine in theory But only if you assume that the data being transferred is public, right? With the described method, any non-privilieged user could access the data from the TCP socket, right?
- marginalia_nu 2y agoInformation in top isn't much of a secret though.
- kevincox 2y agoYes. Any local process can connect to a TCP port (unless special care is taken) so it should be a last-resort option. Additionally the sever either needs to be run as root to bind a privileged port or any application can race over binding that port. UNIX sockets are a much better option as they can be protected by filesystem permissions including who can bind the socket and who can connect to it. This can be mitigated by having authentication inside the socket, but now your authentication code is an attack surface and how are you going to share the secrets? On the filesystem? You are basically back to a UNIX socket with extra steps.
- yjftsjthsd-h 2y agoAh, there's the other shoe:) > optional sources, that have to be activated explicitly. So only locally exploitable, and you have to enable an optional feature? That's ... honestly better than I was worried that it might be
- immibis 2y ago> always tries to connect
- MattPalmer1086 2y agoThe fix is to make it optional. But yeah, I was anticipating something quite a bit worse.
- dgacmu 2y agoNo. Local but it always tries to connect and the deamon to which it tries to connect is optional, which means that the default is attackable. An attacker can run their own program on the port and send bad strings that will cause an overflow.
- yjftsjthsd-h 2y agoOh, I see, thanks. > Therefore, the default behavior of atop is now not to connect to the TCP port at all. I missed that now it defaults to not connecting.
- mvdtnz 2y agoDid you stop reading at that sentence?
- yjftsjthsd-h 2y agoUnlikely, since the use of a local TCP part was later than the quoted sentence. Granted, I did skim, but after having it clarified and rereading, I think that introduction is misleadingly phrased and would benefit from clearer delineation of the previous vulnerable behavior and the fixed behavior.
- echoangle 2y agoRelated: "You might want to stop running atop" - https://news.ycombinator.com/item?id=43477057 https://news.ycombinator.com/item?id=43477057 "Problems with the heap" - https://news.ycombinator.com/item?id=43485980 https://news.ycombinator.com/item?id=43485980
- dang 2y agoThanks! Macroexpanded: Problems with the heap - https://news.ycombinator.com/item?id=43485980 https://news.ycombinator.com/item?id=43485980 - March 2025 (93 comments) You might want to stop running atop - https://news.ycombinator.com/item?id=43477057 https://news.ycombinator.com/item?id=43477057 - March 2025 (139 comments)
- unsnap_biceps 2y agoIt's unfortunate that Unix sockets isn't being used for local connections like this.
- ajross 2y agoMeh. This isn't a technology choice problem. Routine unix sockets are just some file in /tmp which an attacker could likewise open by racing against the daemon in the same way. It's true you could use a privileged spot in the filesystem and set things up to use that by writing some simple extra software, but it's equally true that you could lock down a TCP socket to a specific process with about the same amount of work. Bottom line is that you need to validate your input from outside the process if you're running in a privileged context[1], and atop didn't. [1] It's not mentioned in the linked email, but I assume the core problem here (and the reason it got a CVE number) is that the atop binary is setuid?
- radlad 2y ago> but it's equally true that you could lock down a TCP socket to a specific process with about the same amount of work. Can you educate me? I'm familiar with SO_PEERCRED that returns the user/group/pid on the other end. Would you then checksum the exe of the pid from /proc?
- ajross 2y agoYou can check socket credentials, indeed. You can set up filtering rules to match on UID using nftables. You can do things like put a cookie somewhere else to exchange and authenticate the connection a-la xauth. You could use TLS and check the host key vs. a public key stored at install time. There are many ways to do this, none of which require more than a few dozen lines of code/config. But really the simplest thing would just be to use a port <1024 so that only root can open it. That's literally what the feature was for. You can still be "attacked", but only by someone who already has local root.
- 3np 2y ago
- nubinetwork 2y agoatop freaks out if it isn't talking to the thing it thinks it's talking to... who would have thunked it... I feel like a lot of programs have that issue.
- kccqzy 2y agoIt's acceptable to freak out by crashing. It's even acceptable to crash via explicit assertion failure if the developers don't want to write proper error handling. It's not acceptable to crash via segmentation fault.
- dzaima 2y agoIt's to an extent even acceptable to crash via segmentation fault (more specifically, doing whatever unsafe exploitable things may come of the source of the issue) if it takes the same amount of privileges to cause the crash as the thing crashing has. And that's the important thing violated here, atop being rather reasonably ran by root to examine root processes, whereas the exploiter just needs the ability to host a thing on a specific port.
- uecker 2y agoA segmentation fault is perfectly fine as long as an attacker can not cause any other action before it (but I guess this is the case here).
- Polizeiposaune 2y agoAh, but will it always segementation fault? It can be difficult to prove that an out-of-bounds memory reference triggered by malformed input will always result in a segmentation fault instead of a read or write of an "interesting" memory location.
- uecker 2y agoThis depends. In this, I guess the issue is that there is some oob memory reference. But for example a null pointer deference resulting in a segmentation fault is not (necessarily) a security problem.
- stiild 2y agoI have a semi-related question.For someone whose main job is not maintaining or running full linux servers but would like information about processes and their RAM/CPU..etc. What would be a good tool that is easy to parse with good defaults?
- candiddevmike 2y agoNode exporter is a good start, or you could look at Netdata
- edoceo 2y agoThe tool btop was suggested in the other thread to replace atop and htop.
- 0manrho 2y agoSeconding btop++, been running it as my main top for a few years now, and switched from htop. I didn't have a single complaint about htop, did what it said on the tin and did it well in my experience, but personally I prefer btop's ux/ui.
- calvinmorrison 2y agohtop is a decent curses processes manager that's a few miles better than top
- worthless-trash 2y agoIf you are writing software to parse it, dont use third party tooling. Read the kernel outputs directly (/proc/ /sys etc). While they do have no guarantee not to change, if they do change any tool you are parsing will also be broken.
- Zardoz84 2y agoI recommend nmon
- ezekiel68 2y agoI recommend.. atop, now that it has been updated to address this issue.
- Havoc 2y agoThat sounds less bad than expected
- ianbutler 2y agoHey guys we commented on another thread from a few days ago about our tool Bismuth finding the bug (along with a sha of our reproducer script for proof) https://news.ycombinator.com/item?id=43489944 https://news.ycombinator.com/item?id=43489944 After disclosing and having correspondence with Gerlof and from his above post it looks like we did in fact nail it and I've just shared our write up on how we got it. HN post detailing how we got it: https://news.ycombinator.com/item?id=43519522 https://news.ycombinator.com/item?id=43519522 Edit: Here's our reproducer and we've added it to the post too: https://gist.github.com/kallsyms/3acdf857ccc5c9fbaae7ed823be0365e https://gist.github.com/kallsyms/3acdf857ccc5c9fbaae7ed823be...
- saagarjha 2y agoWhat is that a hash of?
- ianbutler 2y agoAs noted, our reproducer script
- saagarjha 2y agoRight, but where’s the script?
- ianbutler 2y agohttps://gist.github.com/kallsyms/3acdf857ccc5c9fbaae7ed823be0365e https://gist.github.com/kallsyms/3acdf857ccc5c9fbaae7ed823be... From my co-founders account
- saagarjha 2y agoCool, thanks for adding it. It would also be nice if you posted how you generated the hash :) I’m not trying to be annoying but this is a critical part of how these hashes work; you post the hash early to indicate you have some information early and then later you demonstrate that by actually presenting the artifact with that hash. If you don’t publish the artifact so people can check that it is actually what you claim it is then your hash is worthless (as nobody can prove it’s not, like, the hash of a cat photo). And you’d generally want to demonstrate how you generated the hash just so people don’t have to figure out whether to md5 or sha1sum it.
- taspeotis 2y ago> the parsing of the strings is improved to avoid that heap problems can occur. Tell me what language you’re using without telling me what language you’re using…
- geerlingguy 2y agoThis doesn't seem nearly as nefarious as the post from earlier this week indicated... I had expected a full supply chain compromise or something that bad based on the earlier post.
- f33d5173 2y agoYeah being taciturn was really the worst thing you could do
- barotalomey 2y agoYea, my first thought was this is a unrelated find because eyeballs since the recent focus.
- amiga386 2y agoSo, as https://www.cve.org/CVERecord?id=CVE-2025-31160 https://www.cve.org/CVERecord?id=CVE-2025-31160 says: * CWE-617 Reachable Assertion * affected from 0 through 2.11.0 ... can we assume these will be updated to the actual vulnerability (CWE-940, CWE-120?), and vulnerable versions (2.4.0 through 2.11.0)? Or was the vaguepost about an entirely different vulnerability? Does anyone yet know what specific issue the vaguepost was alluding to?
- cullenking 2y agoI was bit by atop a few years back and swore it off. I would get perfectly periodic 10m hangs on MySQL. Apparently they changed the default runtime options such that it used an expensive metric gathering technique with a 10m cron job that would hang any large memory process on the system. It was one of those “no freaking way” revelations after 3 days troubleshooting everything. Interesting reading through the related submission comments and seeing other hard to troubleshoot bugs. I don’t think atop devs are to blame, my guess is that what you have to do to make a tool like atop work means you are hooking into lots of places that have potential to have unintended consequences.
- mvdtnz 2y agoSo what was the point of Rachel's vagueposting? Was there any kind of NDA or a good reason to be so vague?
- brazzy 2y agoResponsible disclosure?
- Zardoz84 2y agoomg .. Why a TCP port instead of using a UNIX socket ?
- Galanwe 2y ago> The vulnerability is caused by the fact that atop always tries to connect to the TCP port of 'atopgpud' during initialization. When another local program has been started (instead of 'atopgpud') that listens to this TCP port, atop connects to that program. Such program is able then to send unexpected strings that may lead to parsing failures in atop. These failures result in heap problems and segmentation faults. Okay, so, if I have a shell and the rights to listen on a host, I can crash the "atop" of other users? That's it ? I could also create a fork bomb, fill up the disk, use all CPU and memory, etc...
- bitbasher 2y agoI think the concern is for privilege escalation.
- TonyTrapp 2y agoNot the same thing at all if atop runs as root and you are a user on that system that has no root access. With a well-prepared exploit you could achieve code execution as root. That's a bit more than a simple Denial of Service by filling up the disk.