Enjoy!
First of all your video is awesome.It is great.
I don’t understand why we are giving the setuid(0) .
For ‘0’ it represents root user i knew it.
But this binary why we are giving setuid() please answer me dude.
I don’t understand.
because you want to set user id equal to 0 for this binary, means execute using root privileges.
dude i knew to execute as root we have to use uid => 0 . because root uid is 0.
But this is not my question.
For this (grabage) exploit only we are giving setuid() function at payload.
why we have to give this setuid().
garbage is already suid in permission,then why we have to it once again at payload.
why we are calling setuid() function at payload.
Other exploit we don’t call setuid() function.
Take a look at the flags set in the file and you’ll notice the suid-flag is set. The file flags look like this:
-rwsr-xr-x (note the ‘s’ in there)
Take a look at the passwd file, you’ll see the same flags set.
This means that this program can be executed as a normal user but may elevate its own permissions via code. With passwd for example this is necessary because you need to be able to change your own password, which requires the program to have the permission necessary to read and write the shadow password file, which is root only, but you have to be able to run it with your user privs only, even if you have no sudo rights on the machine you should be able to change your (and only your) password.
You run the exploit as the normal user. Without calling setuid, you would run the program with the permissions of your user. But by calling setuid in a file like this (with the suid-flag set) means that you change the permission settings to the user you specify (in this case 0, i.e. root).
This exploit works ONLY because the setuid-flag ist set. And it goes without saying that files that have the flag set should be very well audited and checked for flaws because … well, you have seen first hand what happens if you don’t.
Another flag you want to look out for is the setguid-flag. Same reason. There, you’d have an s in the group triple of the permission flags instead of the owner triple.
P.S. Just watched the video, he pretty much explains it at 33:00. Could’ve saved me all that typing just by watching…
You have to call setuid(0) because of a bash security feature. The setuid flag of the garbage file only sets the effective uid to 0. The real uid stays the one of the user calling bash. When bash detects that the effective and the real uid do not match, it drops the privileges.
To prevent this you can call setuid(0) before calling bash. So if you want to run bash from a setuid binary, you have to run it through a setuid wrapper. In the ellingson exploit the setuid() call is directly included in the ROP chain.
See here for details on the bash security mechanism:
Great dude.Thanks for response