2

As part of the recent "rowhammer" exploit proof-of-concept, a read-suid-exec tool "ping" was used to create a more finely tuned proof of concept.

And so my question - why do various distributions prepare suid (especially root) executables as readable as well as executable?

My speculations include:

  1. Convenience for use with "ldd"
  2. To allow tripwire or package-update checking software to run as non-root
  3. It doesn't matter since most distributions are public and the ELF binary can be gotten by anyone (installing into a VM, etc.)
  4. selinux can be used to make this irrelevant
  5. Lazy developers

With (3), hiding the binary of a public distribution offers only a fig-leaf of security - and (5) is pretty much name calling.

Richard Conto
  • 78
  • 5
  • (3) is answer enough, is it not? Download the package itself, run an appropriate equivalent to `rpm2cpio`, and you have the binary -- no VM or root privileges needed. – Charles Duffy Mar 16 '15 at 21:10
  • BTW, http://security.stackexchange.com/ might be the better place for this question. – Charles Duffy Mar 16 '15 at 21:11
  • Thank you for suggesting SECURITY.STACKEXCHANGE.COM. Given that security must be in layers, having a figleaf can be worthwhile (given that the access mode is cheap to implement) - if only because it would require any malware to encode more information. – Richard Conto Mar 17 '15 at 16:09

2 Answers2

0

Not a complete answer, but I found that I needed to make setuid root programs readable if they were stored on an NFS server.

Let me say again: On a local file system chmod 4711 was enough for setuid root programs, but on NFS the required mode was 4755.

fork2execve
  • 1,561
  • 11
  • 16
0

It's a mixture of "it doesn't matter" (3) and "lazy developers" (5).

It's good practice to turn off unnecessary permissions such as read access on SUID executables because it can reduce attack surface generally, but in many cases it doesn't make much difference.

As you say for (3), hiding the program data doesn't stop attackers searching for ROP gadgets etc. because the data is typically visible in the public distribution that the binary came from.

Note that that doesn't apply to the rowhammer-based exploit described in the Project Zero blog post. For that, the exploit doesn't want to read the data in the SUID executable, it just wants to use /proc/self/pagemap to learn which physical addresses contain the executable's data.

However, as the blog post says, if the attacker can't open() the SUID executable, it can just open() a library it uses, such as /lib64/ld-linux-x86-64.so.2, and apply the exploit to that. So restricting read permissions on the SUID executable doesn't help. We can't remove the read permission on these libraries otherwise they would be unusable.

Mark Seaborn
  • 1,392
  • 13
  • 11