Linux Shellcoding with SuSe 9.3 - odd problems

[Cryptic_Prime]

Hello everyone.

(FYI, I have scoured the Internet and spent two weeks on this before I finally decided to join here and post.)

I have been going through all of the standard "learning to shellcode" papers by Aleph1,etc.etc. (some found at www.l0t3k.org/programming/docs/shellcode/ ) I also have been going trough the Shellcoder's Handbook (wow, what a lot of mistakes in there!) and Hacking: The Art of Exploitation.

Regardless of book or tutorial, I keep running into the same problem:
No matter what the shellcode or method of exploitation, I can never seem to get UID=0 unless the vulnerable program specifically calls setuid(0). Yes, the shellcode contains those instructions also.

I am using SuSe Linux Pro. 9.3 with kernel 2.4.21-99-default.
According to the release notes, as of SuSe 9.1, there is a non-executable stack.
However, when I look in my kernel options, it is disabled (or so it appears).
In addition, there is no exec shield stuff running either.
Also, the correct ownership & permissions are set for the vulnerable program.

Just curious to figure out if I am doing something wrong and if somebody can offer some pointers. Does SuSe or this kernel have protection I have yet to discover?

Thanks.

[Voltage Spike]

I'm not sure how helpful this will be, but are you running the shell code as root or merely SUID? I ask because I have run into problems in the past that stemmed from my Linux machine refusing to honor the SUID bit for shell scripts when the user was root.

[Cryptic_Prime]

I'm not sure how helpful this will be, but are you running the shell code as root or merely SUID? I ask because I have run into problems in the past that stemmed from my Linux machine refusing to honor the SUID bit for shell scripts when the user was root.

I have a seperate user called 'attacker' that I run everything as.
I am even logged into X as this user and 'su' to root to set permissions, etc. (just to be SURE I am 'attacker')

Speaking of permissions...this is what I am using for the vulnerable executable:

chmod 0755 vuln
chmod ug+s vuln
chown root.users vuln

So, the exploiting program is run as 'attacker', it runs the vulnerable program from within itself using the execl().

Thx.

[Voltage Spike]

chmod 0755 vuln
chmod ug+s vuln
chown root.users vuln

The "s" portion of your chmod command is the SUID bit, and you set the owner to root. As I said, this will not work as your system is protecting root from making a bad mistake.

[Cryptic_Prime]

The "s" portion of your chmod command is the SUID bit, and you set the owner to root. As I said, this will not work as your system is protecting root from making a bad mistake.

That's odd...everything I've read said to set this bit to be able to exploit it...

hmmm....just as an experiment to test this, I exploited a test program with and without this sticky bit. I made a version with and without setuid(0) inside the program just to make sure...got some interesting results:

Results (ran as attacker):

With sticky bit: no root shell.
Without sticky bit: no root shell.
With sticky bit and with setuid(0): root shell (yeah!)
Without sticky bit and with setuid(0): no root shell.

My head asplode....

[Cryptic_Prime]

Problem Solved - good info for all to know.

OK, I think I have solved the great mystery.

If you pull out your copy of "Hacking: The Art of Exploitation" (what? everyone doesn't have a copy?!), and turn to page 129-135, you will find the solution.

Apparently, the /bin/sh call drops privilages (according to Erickson).
So you have to use one of the execv() calls.

I was using execl(), but not in the right way...I was using excel() which later called
/bin/sh which then dropped the privelages.

The best book ever on shellcoding is "art of exploitation."
Amazing amount of info.

Anyway thanks for the help Voltage Spike.

[MidnightViper]

I've read a summary about the book on ThinkGeek, but I have yet to pick it up. I might actually order it tomorrow at work and see what it's like. (I work at Barnes and Noble).

Great choice in OS also man. I'm currently running SuSE 9.3 Pro as well. It's just so flexible!

[Syn/Nop/Sys]

Sorry, I may be mistaken, but using different function calls (exec(), execv(), execl() and family) won't circumvent the drop-root priveledges problem.

The only way to stop the program from dropping root priv's is to use a portion of the shellcode to insert assembly instructions which will forcfully pick up those privledges again.

Using exec() used in conjunction with a command-shell-script is the simplest of overflow methods, but it is not used to stop the program from dropping priv's, and similarly using execv() just creates an array which represents a linux environment and attaches this to the program, wherein the shell will be stashed, this is used when the buffer to overflow is to small (Erickson: the AOE).

Personally:

I loved the Art of exploitation, it is a brilliant book for hackers, but Cryptic_prime, dude, you said

The best book ever on shellcoding is "art of exploitation."

Well as I said I loved that book, but it is by no means the best on shellcoding, I mean there are tons of others and the AOE is an excellent contribution to hacking. OK, to substantiate what I'm saying you should check this book out: "Buffer Overflow Attacks - Detect, Exploit and Prevent" (Publisher: Syngress; Author: James C. Foster) now that's a book and a half on overflows.

Dude, PM me if you wanna talk about aquiring a copy!!!