HN

Comments (84)

• Menu

  EdiX
  I 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.
• Menu

  NobodyNada
  Both 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/
• Menu

  ianbutler
  Hey 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: 1d53b12f3bc325dcfaff51a89011f01bffca951db9df363e6b5d6233f23248a5And now we're going to go responsibly disclose what we have to the maintainers.
• dang
  Recent and related:You might want to stop running atop - https://news.ycombinator.com/item?id=43477057 - March 2025 (131 comments)
• Menu

  john-h-k
  as 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 badeither this is correct, or cunningham’s law will bring out the correct interpretation
• Menu

  baltimore
  Same author in March 2014 was having segfault issues with atop apparently: https://rachelbythebay.com/w/2014/03/02/sync/
• trismegisti
  It 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.
• Menu

  bee_rider
  RachelByTheBay underestimated how much we hang on her every word over here, I think. Haha.
• nsxwolf
  I found this hard to follow, like it was in the middle of something.
• Menu

  ultrarunner
  This reads like it's referencing something specific. Am I out of the loop or is this just about heap exploits in general?
• mary-ext
  A vulnerability can be high risk, a vague disclosure means that people can only assume the worst.Maybe don't vaguepost about vuln disclosures
• titaphraz
  Responsible disclosure has been a thing for a long time. This is not a professional behavior.
• halayli
  You 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.
• anon
  undefined
• Menu

  judofyr
  > 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?
• Menu

  th0ma5
  Check out this https://github.com/Atoptool/atop/issues/330 possibly related GitHub issue?
• hackburg
  [dead]
• curtisszmania
  [dead]
• Menu

  KerrAvon
  [flagged]