8 ms·
Problems with the heap
- bee_rider 2y agoRachelByTheBay underestimated how much we hang on her every word over here, I think. Haha.
- anitil 2y agoI believe she hasn't had the best behaviour from our members unfortunately
- simoncion 2y agoI expect she's had the best behavior that the members in question are capable of.
- wglb 2y agoI think it has gotten better of late.
- neuroticnews25 2y agoCan you expand on this? I'm new here and I have been binge reading her posts recently.
- anitil 2y agoI'm going from memory but I think when posts of hers get traction here she'll get comments that I think she refers to as 'The One' [0], and also comments that... you typically wouldn't get for a male poster. [0] https://rachelbythebay.com/w/2018/04/28/meta/ https://rachelbythebay.com/w/2018/04/28/meta/
- ultrarunner 2y agoThis reads like it's referencing something specific. Am I out of the loop or is this just about heap exploits in general?
- dan353hehe 2y agoA post from them yesterday made it to the front of HN. https://news.ycombinator.com/item?id=43477057 https://news.ycombinator.com/item?id=43477057 Edited to be the HN post.
- bee_rider 2y agoThere was a post yesterday https://news.ycombinator.com/item?id=43477057 https://news.ycombinator.com/item?id=43477057 Which was sort of strongly reacted to (atop is wide spread and the blog author has a bit of a following here).
- KerrAvon 2y ago[flagged]
- perching_aix 2y agoI don't get comments and commenters like this. [0] It's unquestionably an "improvement" over the original, provided we measure that by the amount of information provided, which is the obvious way to measure it for every normal human being. Yes, the author is very clearly dancing around something. No, nobody here knows why either. No, they don't have a damn concussion, and their post really isn't a difficult read at all. Your ideas about NDAs are speculative (according to yourself). Why are you taking them at face value? [0] But maybe this is just my variation on when people in YouTube comment sections get mad at each other for quoting the zingers from the corresponding videos, so eh...
- deleted 2y ago[deleted]
- baltimore 2y agoSame author in March 2014 was having segfault issues with atop apparently: https://rachelbythebay.com/w/2014/03/02/sync/ https://rachelbythebay.com/w/2014/03/02/sync/
- pdpi 2y agoRachel's been a reliable source of interesting issues like these for the better part of eternity now. Her blog's well worth reading.
- oguz-ismail 2y ago[flagged]
- Niten 2y ago[flagged]
- usefulcat 2y agoAfter reading that: atop should've used SQLite.
- th0ma5 2y agoCheck out this https://github.com/Atoptool/atop/issues/330 https://github.com/Atoptool/atop/issues/330 possibly related GitHub issue?
- OptionOfT 2y agoThere haven't been any releases of atop since Jul 27, 2024, v2.11.0. Are people building atop themselves? https://archlinux.org/packages/extra/x86_64/atop/ https://archlinux.org/packages/extra/x86_64/atop/ shows 2.11.0-1, not updated since 2024-07-31 11:02 UTC https://packages.debian.org/sid/atop https://packages.debian.org/sid/atop & https://packages.ubuntu.com/oracular/atop https://packages.ubuntu.com/oracular/atop show 2.10.0-3, not updated since Fri, 31 May 2024 13:42:28 +0200 (https://metadata.ftp-master.debian.org/changelogs//main/a/atop/atop_2.10.0-3_changelog https://metadata.ftp-master.debian.org/changelogs//main/a/at..., https://changelogs.ubuntu.com/changelogs/pool/universe/a/atop/atop_2.10.0-3/changelog https://changelogs.ubuntu.com/changelogs/pool/universe/a/ato...)
- john-h-k 2y agoas there seems to be some confusion, this is my interpretation: atop is (for some reason) touching memory of processes it monitors. atop is touching this in an insecure way. An executable can cause atop to corrupt its memory. this has high potential (although not guaranteed) for allowing RCE within atop via a correctly crafted process that atop monitors. atop is often run in root, and so this otherwise meaningless RCE becomes privilege escalation, which is bad either this is correct, or cunningham’s law will bring out the correct interpretation
- shanemhansen 2y agoThis is a complete shot in the dark but wild speculation is fun. If atop had a buffer overflow when reading a process name (changeable at runtime using $0 in perl for example) this would be the kind of issue I expect. Similarly, some other value that was expected to be null terminated but wasn't.
- twic 2y agoMy guess is that it tries to decode the malloc metadata, which involves chasing pointers, and doesn't do enough sanity checking, so if a process accidentally or deliberately sets up corrupt metadata, atop will dereference an invalid pointer and explode itself.
- dang 2y agoRecent and related: You might want to stop running atop - https://news.ycombinator.com/item?id=43477057 https://news.ycombinator.com/item?id=43477057 - March 2025 (131 comments)
- curtisszmania 2y ago[dead]
- judofyr 2y ago> Okay, first off, everybody breathe. Everyone is freaking out. This is not the way to do this. Why are you doing it this way then?
- keyle 2y agoYeah that's a half-assed apology. Yesterday's post might have unintentionally sent a lot of heads spinning, "this is not the way to do this" is not an apology, it's a double-down. I understand there is a potential heap overflow with atop, thanks for letting everyone know; but you're also letting the people capable of taking advantage of it aware that there is possibility to do this in the wild. Due process is let the developers fix it and then tell everyone to upgrade. Anyway a C process that runs as root for lifestyle purposes (e.g. not a critical service) is a big no-no. And I say this as I like to write C, I love C. But I wouldn't push my C code on anyone else's computer, especially requesting root access. I'm not that good.
- achierius 2y agoI would give her the benefit of the doubt and presume that the responsible parties were informed some time ago.
- Niten 2y ago[flagged]
- gjm11 2y agoShe does when she writes books (e.g. https://rachelbythebay.gumroad.com/l/bozo-loop-epub https://rachelbythebay.gumroad.com/l/bozo-loop-epub). She doesn't have her full name in the name of her blog because, well, whyever should she? (You are writing here under the name "Niten" which I am going to guess is not your full name. I am writing under the name "gjm11" which is also not my full name, though as it happens my full name is readily discoverable via my HN profile while yours is not. Obviously neither of us actually believes that there is something wrong with not stating your full name explicitly every time you write something.)
- NobodyNada 2y agoBoth of the error messages we're given indicate that the "top" chunk of the heap was corrupted, which is a special internal allocation used by glibc malloc to represent any unused capacity from the last time malloc decided to grow the heap: high memory addresses ("top" of heap) | unmapped memory | |-----------------| | | | top chunk | | (mapped, but | | not yet | | allocated) | | | |-----------------| | allocated chunk | |-----------------| | freed chunk | |-----------------| | allocated chunk | | | |-----------------| | allocated chunk | |-----------------| | freed chunk | |-----------------| | tcache | |-----------------| low memory addresses ("bottom") of heap That likely indicates a heap buffer overflow. If a call to malloc() doesn't find a freed chunk, it will split the top chunk in two and return a pointer to the bottom portion. If you then write past the end of the returned allocation, you clobber the metadata of the top chunk, and get errors like the ones in the article. With the exploit mitigations built into modern Linux and glibc, it's a lot of work to go from here to arbitrary code execution; but it very well may be possible, depending on exactly how much control the attacker has over what atop does. The attacker can probably trigger the heap buffer overflow multiple times by spawning multiple processes, and if the length and contents of the heap buffer overwrite are attacker-controlled, they can probably play some games to overwrite any data stored in the heap. If that's true, the only thing preventing full arbitrary-code-execution is ASLR; there are many clever ways to get around that, but it's often quite difficult and may or may not be possible here. This year's LACTF had a challenge with essentially this exact setup. My solution writeup is a good example of what it takes to defeat the exploit mitigations and turn a heap buffer overflow into an RCE: https://jonathankeller.net/ctf/lamp/ https://jonathankeller.net/ctf/lamp/
- progmetaldev 2y agoI thought I would ask, does this mean that memory restricted environments can be a better target for attack than one with a large amount of memory available? In my mind it seems like this would be the case, but I'm not sure if there is anything in place to protect these types of environments, like intentionally breaking up and segmenting memory so it's not possible to read much linearly. I admit that I haven't touched low-level code since the early 2000's, and earlier than that for anything other than a course requirement, so I apologize if you explained it in your linked article and I don't understand.
- ianbutler 2y agoHey guys so I work on a tool call Bismuth along with my co-founder for finding and fixing bugs and we think we have this. At the very least we have a bug in atop which mimics what is being described. We're going to throw this sha down right here: 1d53b12f3bc325dcfaff51a89011f01bffca951db9df363e6b5d6233f23248a5 And now we're going to go responsibly disclose what we have to the maintainers.
- ianbutler 2y agoWe've reached out to the maintainer over e-mail.
- Retr0id 2y agoBased on the bug you've found, do you think it's exploitable beyond DoS?
- __turbobrew__ 2y agoThank you for doing this instead of just vagueposting and wasting everyone’s time.
- vanderZwan 2y agoI'm inclined to expect that we should put the blame for that on whomever used legal channels to force Rachel to shut up, although obviously the jury is still out until we know more.
- supriyo-biswas 2y agoThis is the only explanation that makes some sense, otherwise it would be just a dick move for someone to hint at the presence of an exploitable bug but then not say what exactly it is.
- immibis 2y agoNot telling you how to hack a whole bunch of computers until the bug is fixed is called responsible disclosure. It's very popular, and depending on how the government is feeling that day, may be illegal not to do.
- nsxwolf 2y agoI found this hard to follow, like it was in the middle of something.
- mary-ext 2y agoA vulnerability can be high risk, a vague disclosure means that people can only assume the worst. Maybe don't vaguepost about vuln disclosures
- EdiX 2y agoI gave her the benefit of the doubt initially, she usually posts good posts, but this is not the way to do things. Vagueposting about a security vulnerability without properly disclosing it to the mantainers: (1) damages their reputation, (2) sends every blackhat on the hunt like a real life worldwide CTF event, (3) leaves sysadmins in the dark unless they are following this specific random blog and (4) since the details aren't known even if they know it's impossible to determine if they really are affected. Something like this would be justified if the maintainers were unresponsive and it was a remotely exploitable bug. Now it turns out this is probably a minor thing (local privilege escalation if you happen to be running atop as a privileged user). It seems to me like an irresponsible, egocentric way to handle things.
- ynik 2y agoAt least on Debian, installing the `atop` package will automatically install a background service running atop as root. (by default, logging some stats to /var/log/atop/ every ten minutes)
- nukem222 2y agoEh, finger pointing does nobody any good, emphatically including this comment. Finger pointing towards someone who actually found a vulnerability is just bleak. I would not willingly associate with anyone who engaged in such behavior. Maintaining software is hard, but this does not imply a right to be babied. People should simply lower their expectations of security to match reality. Vulnerabilities happen and only extremely rarely do they indicate personal flaws that should be held against the person who introduced it. But it's your job to fix them. Stop complaining.
- whatnow37373 2y agoI never quite understood why computing is so different from literally all other branches of reality. Systems need to be secure, I get it. But if we have a bunch of folks dedicating their life to breaking your shit I don't get how that is in any way acceptable and why the weight of responsibility solely lies with people responsible for security. We apparently have a society/world that normalizes breaking everyone's shit. That's not normal - IMO. If I break into a factory or laboratory of some kind and just walk out again I have not found a "vulnerability" and I certainly won't be remunerated or awarded status or prestige in any way shape or form. I will be prosecuted. Everyone can break into stuff. It's not that stuff is unbreakable, it's that you just don't do that because the consequences are enormous (besides obvious issues with morality). Again, breaking stuff is the easy part. I am certainly completely ignorant and should be drawn and quartered for it, but for me it is hard to put my finger where I'm so wrong. I can see how the immaterial nature of software systems changes the nature of the defense, but I don't see how it immediately follows that breaking stuff that's not allowed to be broken by you is suddenly the norm and nothing can be done against that. We just have to shrug and accept our fate?
- halayli 2y agoYou need to establish the causal link between user1 doing something and atop segfaulting. That link is what determines whether there's a potential exploitability to take advantage of. it's easy to think of a scenario where user1 is using almost all the memory on the system and user2 runs atop and segfaults because atop is missing a memory check and overcommit is disabled, or user1 deletes a file that can cause another app to crash given the wrong permissions on the file.
- trismegisti 2y agoIt would be very surprised if this isn't just an atop bug. Can it be exploited? Considering the error messages, the possibility is high. I don't like to see it as "Problem with the heap". As someone who played lots of CTF and is quite sufficient in exploiting such bugs, i would much rather see those things framed as "Problems with the glibc allocator". If we just wouldn't use inline metadata, or verify it's integrity (smth like scudo but not broken), all of the security issues with the heap would just be gone. If you get to work with frameworks/languages that are more flexible when it comes to allocate memory (thinking about zig and it's amazing allocator abstraction here) you quickly realize that malloc and free are an insanely simplistic api for what is one of the most difficult and important problems in programming: memory allocation. There is also no excuse for the error messages being that bad. Because the reality is that most systems programmers will have to debug those at some point.
- titaphraz 2y agoResponsible disclosure has been a thing for a long time. This is not a professional behavior.
- hackburg 2y ago[dead]