[HN Gopher] CVE-2025-31160 Atop 2.11 heap problems
___________________________________________________________________
CVE-2025-31160 Atop 2.11 heap problems
Author : baggy_trough
Score : 41 points
Date : 2025-03-29 20:43 UTC (2 hours ago)
(HTM) web link (openwall.com)
(TXT) w3m dump (openwall.com)
| yjftsjthsd-h wrote:
| Ah, 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 wrote:
| > always tries to connect
| MattPalmer1086 wrote:
| The fix is to make it optional.
|
| But yeah, I was anticipating something quite a bit worse.
| dgacmu wrote:
| No. 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.
| mvdtnz wrote:
| Did you stop reading at that sentence?
| echoangle wrote:
| Related:
|
| "You might want to stop running atop" -
| https://news.ycombinator.com/item?id=43477057
|
| "Problems with the heap" -
| https://news.ycombinator.com/item?id=43485980
| unsnap_biceps wrote:
| It's unfortunate that Unix sockets isn't being used for local
| connections like this.
| ajross wrote:
| Meh. 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?
| johnmaguire wrote:
| > 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 wrote:
| You 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.
| zitterbewegung wrote:
| Is it just me or does this seem like a bad design where a TCP
| port is exposed to share information?
| marginalia_nu wrote:
| As long as you bind to localhost it's fine in theory. Though
| any network code still needs to be rigorously hardened.
| echoangle wrote:
| > 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?
| kevincox wrote:
| Yes. 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.
| nubinetwork wrote:
| atop 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.
___________________________________________________________________
(page generated 2025-03-29 23:00 UTC)