Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

What exactly is IP spoofing and IP forwarding? How does it work and why use it?

I also have some questions about how crackers exploit a buffer overflow. What is a buffer overflow (I have a clue about it but am not entire sure). I just read in a book that mentioned that when exploiting a buffer overflow the exploit could change where the function should return after being executed to make it return to the crackers own program/code.

I know a little about programming in C/C++ so I know about how functions work and so on.

Buffer overflow is probably the most prevalent and probably the most dangerous security flaws out there today. There is a lot of documentation out there on the subject, but in short, it usually has to do with poor coding allowing a user to overflow the stack with useless data and then causing his own code to execute off the stack (usually code that has a "call back" feature allowing remote root access to the comprimised machine). A really bad flaw to have in your code!

Some hardware vendors, namely AMD, is trying to produce a chip that prevents this type of overflow by stopping it at the hardware level (since this is easier done than having to training all programmers to write secure code

A simple google search will give you more details on this and the other questions you had.

Thanks for all help on the subject. But all this was a little to much to understand so I copied some codes from that "Smashing the stack for fun and profit" but I could not really understand how the exploit there could be used on a bad-programmed daemon running on another server.

So I have now tried to code my own "bad server" which makes an buffer overflow pretty easy. This can be done easy with telnet just to shut it down but I can't figure out how to spawn a remote shell. I understand some of what's being told in "Smashing..." but I don't get the whole thing.

Originally posted by bostontech
Some hardware vendors, namely AMD, is trying to produce a chip that prevents this type of overflow by stopping it at the hardware level (since this is easier done than having to training all programmers to write secure code

Yeah, but thankfully there is no need to go buy pricey new gizmos ...

Some of the fine folks over at IBM produced patches to GCC called ProPolice, which is a software stack protection mechanism. Some of the more secure by default operating systems out there have even included it in their base compilers, and Immunix has StackGuard. While it would be kind of interesting to have this in hardware, I can't see people paying extra for it.

Originally posted by MezzyMeat
I am not sure but I think that you should be able to spawn a remote shell when exploiting this program.

Indeed you can

Quote:

Originally posted by MezzyMeat Now all I have to do is to connect to my host on this port and then send a text large enough to not fit into the 512-byte array. When I do that the server shuts down with "segmentation fault".

What about the shell now? Can it be applied and how the **** does it actually work?

You're only half way there. You know where the overflow is, but now you have to play with a debugger and figure out how many bytes to pass the server past the 512 to overwrite the stack pointer so that you return into your code. Then there is the whole issue of "your code" (or shellcode) which you'll need to craft by hand to suit the particular service you're exploiting (you can get example shellcode off the net). Then you have to pass all this through to the server while avoiding any IDS's along the way (Don't use too many nop()s -- A string of them will get your shellcode busted faster than anything).

Fun, eh?

As for how it works -- When a program calls into a subroutine, the machine takes note of the memory location it's branching from. When the subroutine finishes, the machine looks at the "stack pointer" to see where it should continue execution of the code from. In the case of a buffer overflow, you're overwriting *just* enough stack so that you put the address of *your* code into the stack pointer. That way, when the subroutine returns, the machine runs your code instead of the real program code.

That's about as much detail as I'm going to go into (don't want to upset the moderators). Besides ... shellcode is like anything else. It's better when you learn it the way everyone else did ... The hard way :P

I am getting the big picture of how functions uses return addresses and how the overflow overwrites that to return to the buffer in which I have written a code that spawns a shell. It's starting to clear up.

The thing I do not really understand is how assembler codes work (I maby have to learn that language before I can continue).

And the big question right now is:
Can I just code a program that acts like a client (like telnet). The program connects to the running daemon, creates the fitting data to send to it, sends it, the data overflows the buffer with code to spawn a shell and changes the return address. I just need to know the principles right now.

Code:

-------------------
/* exploit.c */
open socket and bla bla bla
connect the socket to the remote host
create the large amount of data (a lot of work here)
send the data
Then what? "Return 0"? I don't want the exploit to exit on success and kill the spawned shell.
-------------------
gcc -o exploit exploit.c
./exploit host.domain.com 5000 [buffersize] [offset]
(program does everything)
$bashprompt

And don't worry about the moderators, I hope they understand that as many others in the Linux-world even "good" hackers wants to know the technique they are going to prevent.

Originally posted by sigsegv Yeah, but thankfully there is no need to go buy pricey new gizmos ...

Some of the fine folks over at IBM produced patches to GCC called ProPolice, which is a software stack protection mechanism. Some of the more secure by default operating systems out there have even included it in their base compilers, and Immunix has StackGuard. While it would be kind of interesting to have this in hardware, I can't see people paying extra for it.

you shouldnt think thats much of an extra measure of security though. Its better, and you may stop a few helpless script kiddies, but anybody who knows what they're doing knows theres ways around this.

edit: And also, on an interesting note, Microsoft tried this awhile back. The folks over at immunix verified that M$ stack guard was a direct port of immunix's. Also, it was badly ported, leading to a couple of security flaws in the very mechanism that was supposed to provide security.

I wasn't suggesting that stack protection was the "do all end all" of security ... The only thing that will stop buffer overflows is for people who don't understand pointers and memory allocation to stop writing software in languages that lets them shoot themserves in the foot, or to learn proper code technique ...