5

It seems protections are harcoded into sudo that prevent the binary from executing as a low-privileged user. Running it in Ubuntu as a normal user returns the following error:

"sudo must be owned by uid 0 and have the setuid bit set"

Maybe this is an incredibly stupid question: but what's to stop an attacker from compiling their own custom sudo binary that allows it to execute with any uid?

user188691
  • 51
  • 1
  • It can be done, but will only allow anyone to run `sudo` as the attacker uid, not as root, or anyone else. – ThoriumBR Oct 17 '18 at 16:04

5 Answers5

5

what's to stop an attacker from compiling their own custom sudo binary that allows it to execute with any uid?

There's a basic misunderstanding going on here. The program does execute, it just stops when it notices it's not running as the root user. Recompiling the program to remove the check would only allow you to run the task as the user who executed sudo, not root. In other words, the check for running as root in sudo is only an error check and diagnostic, not a security feature.

The misunderstanding is that programs don't have any special ability to execute as another user, the extra privilege is a property of the file permissions on the file. Any program with the setuid bit set will execute as the owner of the file. If you were to compile your own program the file would be owned as you. While you are allowed to set the setuid bit on your own file, you aren't allowed to change file ownership without extra privileges. So setting the setuid bit would only allow others to execute your program as yourself.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
3

To be executed as another user, a file needs to have the setuid permission bit set and needs to be owned by that target user (in this case, root).

what's to stop an attacker from compiling their own custom sudo binary that allows it to execute with any uid?

The permission bits are attributes of a file (which are stored within the filesystem, in the file's inode), they are not contained in the file itself. And your kernel will simply stop an unprivileged user from changing the file owner of their custom compiled sudo binary to root.

Arminius
  • 43,922
  • 13
  • 140
  • 136
3

I think the OP misunderstood the intention of this check. It's not meant to protect sudo from being maliciously misused, but rather a simple precondition for it to function: if it is not setuid by root, it cannot run a command as another user and is thus useless.

billc.cn
  • 3,852
  • 1
  • 16
  • 24
2

Because (except for root) a user can only create a binary which will setuid as their own uid. Only root can change its uid.

symcbean
  • 18,278
  • 39
  • 73
0

Any local user can compile their own sudo binary without this check. But when their copy of sudo tries to do its job of granting privileges, it will receive an error from the kernel, because it doesn't have any special privileges. If sudo isn't running as root, it can't give out any privileges.

The point of the check is that if sudo wasn't installed properly, you get a comprehensible error message early on instead of getting an incomprehensible error message after sudo has done some more processing. It's a diagnosis aid, not a security check.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179