1

Is it possible to use owners privilege instead of current user who is executing the file to perform some action like create a file?

Say I have an executable file which is created by user and can be modified and executed by other users. Is there a way to change the effective uid of the process to owner and operate on behalf of the owner

Mike Ounsworth
  • 59,005
  • 21
  • 158
  • 212
HighNESS
  • 55
  • 2
  • 6
  • 1
    An excellent description of how runtime permissions are determined from our friends at the *nix exchange: https://unix.stackexchange.com/questions/134332/precedence-of-user-and-group-owner-in-file-permissions – David Sep 19 '17 at 18:47
  • sudo, or setuid, but how to do that isn't in scope here; the security implications of using those are. – Xiong Chiamiov Sep 19 '17 at 19:48

3 Answers3

4

Not really sure what you're asking. When you execute programs, they run as you. You can su them to run as another user, but you have to become the other user first (ie you have to know their password).

I think the scenario you are describing is that a file is created by the user victim with the following permissions:

-rwxrwxrwx 1 victim victim exec_file

and you want user to be able to execute the file and have it run as victim.

victim could use setuid to set the special bit of the executable like this:

victim$ chmod u+s exec_file
victim$ ls
-rwsrwxrwx 1 victim victim exec_file

Now when user runs the file, it will run as victim. This is not a vulnerability or an attack since victim explicitly set it up this way.

You might think that the following would work:

user$ ls
-rwxrwxrwx 1 user user exec_file
user$ chmod u+s exec_file
user$ chown victim exec_file
user$ ./execfile  # I'm victim now, right?

but linux will prevent you from doing the chown unless you sudo it, ... but if you have sudo powers already, then this isn't really much of an attack.

The closest thing I can think of to making this an actual attack is if multiple users run this program on a regular basis, and you have write permissions on it, then you can replace it with your own code and wait for the owner (or anybody else) to come back and run it. Now somebody else is running your malicious code as themself. In general, bad idea to give users write permission over files that other users will execute. Far better to have it like this:

-rwxr-xr-x 1 user user exec_file

or even better:

-rwxr-xr-x 1 root root exec_file
Mike Ounsworth
  • 59,005
  • 21
  • 158
  • 212
0

Is it possible to use owners privilege instead of current user who is executing the file to perform some action like create a file?. I mean is it possible to exploit an executable file which is created by user and can be modified and executed by other users.

The answer to the second clarified question is yes, absolutely. If a person creates a file and gives RWX permissions to other users they have full rights to altering and executing that file. Therefore, they have rights to exploit that file even though they are not the owner. This is consistent across Windows and Unix systems.

cclater
  • 135
  • 6
-1

Yes it's possible by using the suid flag on the file: chmod u+s executable_file. You will see, typically, a -rwsr-xr-x when you type a ls -l command.

This mean that the file will be executed with the privilege of the owner of the file. But, you need to be very careful with this flag because it could be a vulnerability if you don't know what the executable do.

For example, the mount or sudo programs are setuid root, because we need the root privileges when using these programs.

An another flag (setgid) perfoms the same but for the group.

You can find more info on the Wikipedia page.

Kjnokeer
  • 11
  • 1
  • I'm not sure I understand, are you suggesting the following command sequence? user$ chmod u+s exec_file, user$ chown victim exec_file, user$ ./exec_file ? If so, I get blocked at the chown step with an "Operation not permitted". – Mike Ounsworth Sep 19 '17 at 19:35
  • because you'll need to "sudo" the command if the outcome of these commands is your intended goal. – cclater Sep 19 '17 at 19:53
  • I mean, if you are the user toto and if the exec_file is owning by root and you perfom a chmod u+s exec_file, the flags will be -rwsr-xr-x. If you run the program (./exec_file), it will be executed with the privileges of the root account and not with toto'privileges. With your command sequence, you are blocked because you don't have the rights to change the owner (you need to have root'privileges). – Kjnokeer Sep 19 '17 at 19:54
  • 1
    @cclater highlights the problem I see with this: if the attack to impersonate another user needs you to have sudo permissions, then how is this any more of an attack than sudo su victim exec_file? – Mike Ounsworth Sep 19 '17 at 19:59
  • @MikeOunsworth but the question here is not about an attack scenario, right? – Kjnokeer Sep 19 '17 at 20:04
  • 1
    @Kjnokeer Either it's about an attack scenario, or it should be closed as "off-topic" for a security forum. I choose to interpret it as an attack scenario. – Mike Ounsworth Sep 19 '17 at 20:05
  • @Mike Ounsworth - Your questions are a bit too vague for me to understand because I don't get what your outcome is. Sudo just means "run as super user" which effectively gives you the rights of the owner in most cases I can think of if sudo is setup on your system that way. But simply saying "if it's run as sudo doesn't that mean it's not an attack" is not a correct statement. An account with sudo rights could be compromised therefore giving the attacker the password to that account and the ability to sudo whatever they want. – cclater Sep 19 '17 at 20:09
  • 2
    @cclater My point is that if the attacker / malicious actor already can already become root, then it's already Game Over. A privilege escalation attack that requires you to already have full privileges - or more generally, sneakily doing something that you're already allowed to do - isn't much of an attack. – Mike Ounsworth Sep 19 '17 at 20:24