undefined

points

[-]

While I hate suid as much as the next person, it's really not the problem here.

The bug that is being exploited gives you basically arbitrary page cache poisoning. At that point it's already game over. Patching a suid program is maybe the easiest way to get a root shell from that but far from the only.

by xorcist15 hours ago|

prev|

[-]

The proof of concept exploit is just that. It is meant to demonstrate one attack vector only. There are many others. If your goal is to prevent the conceptual exploit only then there are many easier ways to accomplish that, such as blacklisting, that does not make you safer.

With this vulnerability you can manipulate the page cache. You could also manipulate ld.so to hook into arbitraty system calls, or set your uid to 0, or any of another dozen or so ways to elevate your privileges.

Mount points have nothing to do with this, even if is always a good idea to disallow suid in user writable areas and prevent reading suid files, but that's for other reasons. NixOS does nothing to fix this and is just as vulnerable as everyone else.

by akdev1l17 hours ago|

prev|

[-]

Without read permissions you cannot execute the binary, that would not make any sense.

To execute the binary it needs to be read from disk and loaded into memory.

In fact if you have read permissions but not executable permissions on a specific binary then you can still execute it by calling the linker directly /bin/ld.so.1 /path/to/binary (the linker will read and load the binary and then jump to the entry point without an exec() call)

by aaronmdjones15 hours ago|

parent|

[-]

> Without read permissions you cannot execute the binary

This is not correct, as when the binary is setuid-someone-else, you are not the one executing it; they are.

  $ cat hello.c 
  
  #include <stdio.h>
  
  int main(void)
  {
      (void) puts("Hello, world!");
      return 0;
  }
  
  $ clang-21 -Weverything hello.c -o hello
  $ sudo chown root:root hello
  $ sudo chmod 4711 hello
  
  $ ls -l hello
  -rws--x--x 1 root root 16056 Apr 30 22:22 hello
  
  $ ./hello
  Hello, world!
  
  $ id
  uid=1000(aaron) gid=1000(aaron) groups=1000(aaron),27(sudo),46(plugdev),100(users)

Removing world-readability from all setuid-root binaries on the system would be sufficient to kill the PoC script provided for this vulnerability. It would not be sufficient to prevent exploitation though; there are many ways to abuse the ability to write to files you have read access to in order to gain root, for example by using the vulnerability to alter the cached copy of a file in /etc/sudoers.d/, or overwrite /etc/passwd, or /etc/crontab, ... the list goes on.

by akdev1l14 hours ago|

parent|

[-]

interesting but in that case no point in keeping the x bit either and suid binaries should just be 4700 ?

by aaronmdjones14 hours ago|

parent|

[-]

If they don't have world-execute permission, an access(2) check for executability would return negative, leading to things like shells not tab-completing it. The kernel would also deny attempting to execute it, as it is not executable for your fsuid.

  $ sudo chmod 4700 hello
  $ ./hello
  bash: ./hello: Permission denied

You need execute access in order to launch it, but in order for it to run, the user it is running as (not you) needs read access; you don't.

by tryauuum15 hours ago|

parent|

prev|

[-]

this ld.so magic will lose the suid bit

    $ /bin/ld.so `which sudo`
    sudo-rs: sudo must be owned by uid 0 and have the setuid bit set

by Plagman17 hours ago|

parent|

prev|

[-]

loader