5

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

  1. 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

  2. I do my exploit => ./file arg=exploit. And get presented with a shell

  3. 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.

Improve this question
5
  • Try echo $EUID rather than whoami.
    – Polynomial
    Nov 23, 2017 at 14:44
  • Get an empty string then
    – Ludisposed
    Nov 23, 2017 at 14:46
  • Could be that the application explicitly drops inherited permissions. What's the context here? Sounds like an academic lab.
    – Polynomial
    Nov 23, 2017 at 14:47
  • Yes this is a lab setup, (wargame)
    – Ludisposed
    Nov 23, 2017 at 14:48
  • 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, 2017 at 16:01

1 Answer 1

Reset to default
8

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).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.