SUID not used after exploit

Question

I know the following

When you execute a program that has the SUID bit enabled, you inherit the permissions of that program's owner.

I am currently user1, but want to read the pass of user2

I verify the SUID bit with ls -l file

user1@ssh/path$ ls -l file
-r-sr-x--- 1 user2 user1 5164 Nov  9 15:08 file

I do my exploit => ./file arg=exploit. And get presented with a shell
To verify if it works I do an whoami.
```
$ whoami
user1
```

I am still the same user?! , and I don't know how this can be.

If more information is needed, let me know.

Could be that the application explicitly drops inherited permissions. What's the context here? Sounds like an academic lab. — Polynomial, Nov 23 '17 at 14:47
I can't tell you have an actual exploit because I don't see the code. But you may need something like `int main(void) { setgid(0); setuid(0); execl("/bin/sh","sh",0); }`, otherwise you're not attempting to use the permissions. — Mark Buffalo, Nov 23 '17 at 16:01

score 8 · Accepted Answer · answered Nov 23 '17 at 15:06

Your understanding of setuid is correct. When you execute a program that has the suid bit, the process inherits the permissions of that program's owner. The piece of knowledge that you're missing is what the shell does after it's been invoked. Many popular implementations of sh drop privileges when they start up: they reset their effective UID to their real UID. This includes bash, dash, mksh and BusyBox sh, so on Linux you won't see anything else.

When the program runs a shell (e.g. by calling the system function from the standard C library, or an equivalent in another language), the shell starts with elevated privileges but drops to ordinary privileges before it executes any user code. This mitigates exploits in setuid programs where the attacker only gets to run a shell command which wasn't intended to run with elevated privileges (e.g. because the shell command was buried in library code that the application programmer wasn't aware of).

This doesn't mitigate exploits where the attacker gets to run arbitrary code. It's just that to get a shell, you have to work a bit harder than calling system. Arrange to call some different interpreter, e.g. run execve("/usr/bin/perl", "/usr/bin/perl") (fork first if you don't want to terminate the parent program).

SUID not used after exploit

1 Answers1

Linked

Related