LinuxQuestions.org - Buffer overflow and ip spoofing

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Buffer overflow and ip spoofing (https://www.linuxquestions.org/questions/linux-security-4/buffer-overflow-and-ip-spoofing-262917/)

Buffer overflow and ip spoofing

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.

One of many explanations on google. (First result, im not claiming its the best =P)

http://www.linuxjournal.com/article/6701

(hows the hdds on the wall going? =D)

This is one of the most famous papers on "smashing the stack" (buffer overflows) on the net.

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.

BTG

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.

A little help here? :)

This is the "bad server" I made and it's called vuln_server.c

Code:

#include <string.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

        

#define BACKLOG 10



// BAD FUNCTION!

void bad_function(char *str) {

        char smallbuffer[512];

        // * * * HERE IS THE REAL RISK!! * * *

        strcpy(smallbuffer, str);

}

                

int main(int argc, char *argv[]) {

        // Check the port

        int port = atoi(argv[1]);

                        

        // Create some stuff to create a socket

        int sockfd, newfd;

        struct sockaddr_in myaddr;

        struct sockaddr_in theiraddr;

        int sin_size;

                

        // Open a socket

        sockfd = socket(AF_INET, SOCK_STREAM, 0);



        // Fix our address

        myaddr.sin_family = AF_INET;

        myaddr.sin_port = htons(port);

        myaddr.sin_addr.s_addr = INADDR_ANY;

        memset(&(myaddr.sin_zero), '\0', 8);



        printf("Running on port: %d\n", port);



        // Bind the socket to our computer

        bind(sockfd, (struct sockaddr *)&myaddr, sizeof(struct sockaddr));

        

        // Start to listen for connections

        listen(sockfd, BACKLOG);

        

        // When connection found, accept() it.

        sin_size = sizeof(struct sockaddr_in);

        if ((newfd = accept(sockfd, (struct sockaddr *)&theiraddr, (socklen_t*)&sin_size)) == -1) {

                perror("accept");

                exit(1);

        } else

                printf("new connection (%s), socket: %d\n", inet_ntoa(theiraddr.sin_addr), newfd);

        

        // Create some messages to send to new connector

        int recvb, sendb;

        char buffer[1024];



        // Infinite loop

        for(;; ) {

                // Let the connector send text and put it into buffer[]

                recvb = recv(newfd, buffer, sizeof(buffer), 0);

        

                if (recvb == 0) { // connection lost!

                        printf("connection lost (%s), socket: %d\n", inet_ntoa(theiraddr.sin_addr), newfd);

                        close(newfd);

                        return 0;

                }

        

                // * * * HERE IS THE BAD FUNCTION * * *

                bad_function(buffer);



                // Send what he sent!

                sendb = send(newfd, buffer, recvb, 0);

        }

        return 0;

}

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

I compile this with gcc -o vuln_server vuln_server.c and then run it:

Code:

$ ./vuln_server 5000

Running on port: 5000

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? :)

Quote:

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.

Quote:

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 :D

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

Thanks, sigsegv.

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

Quote:

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.

That's MicroSoft for ya ...

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

oh, I know. I just dont want anybody to get the wrong idea, and do what these stack guards are making so many people do: think "whew, im safe, now I can code however I want".