Buffer Overflow Lab

In your home directory, there should be a folder called "overflow". Inside it, there are a number of a files. One is called README, a command you should obey. You will see four C programs: overflow1.c, overflow2.c, overflow3.c and overflow4.c. They have been compiled into overflow1 through overflow4, but also as attackme1 through attackme4, respectively. These last four binaries are run "setuid" (or SUID), which means that they will be run with additional privileges, specifically all privileges belonging to the _owner of the binary_, when the kernel executes them. In other words, when you run ./attackme1, the file won't be running under your user, but as a different user (in this case if you're "user", there is a new user called "user_o1" which will run this binary). The reason why setuid binaries excist is that you might want to allow regular users to perform privileged operations, like using the graphics card, ejecting a CD-ROM or spawning an administrative shell (like "su" or "sudo"). Your goal is to write an exploit to make the programs attackme1, attackme2, attackme3 and attackme4 spawn shells as their users, so that you can access their home directories (such as /home/overflow2/user_o2/). Inside this home directory, you should leave a file called "SUCCESS" to signal that you've completed this part of the assignment. Note that "user_02" corresponds to "overflow2", etc. To compromise each of these binaries, you will be writing an exploit for stack overflows that exist in the code. To ensure you got it right, you should be working with gdb on "overflow1". When your exploit for overflow1 is ready (so that it will make overflow1 open a shell), you should try the exact same exploit code on "attackme1". The reason for doing it this way is that gdb won't be able to trace a program owned by a different user, so gdb ./attackme1 is going to fail. However, overflow1 is identical attackme1 so it should all work out. The same holds true for the other overflows. STAGE 1 (20 pts): In overflow1.c, you will be writing a regular stack overflow exploit. We have been talking about how to do this in lectures. For supplementary explanations, check out the good old "Smashing the Stack for Fun and Profit" article ([login to view URL]). The idea is to make the saved %eip value point to the shellcode on your buffer. You can use a NOP sled (series of 0x90 which encode the x86 'nop' instruction) to make the exploit more robust to changes in stack offsets. NOTE: If you are able to spawn a shell, you may still not get the privileges you seek because /bin/bash will shed privileges it obtains unless euid=uid. So you'd need to write a program to do setuid(geteuid()) or something like that. See the README file for more details. STAGE 2 (40 pts): In overflow2.c, you need to be careful with picking a shellcode that doesn´t have any special characters. Sounds like you might want to find an alphanumeric shellcode ... (hint, hint). STAGE 3 (30 pts): In overflow3.c, you need to become a bit more creative. There is little room for maneuver in the malt() routine. The appelsin() routine looks more promising, but it never gets called... (hint, hint). STAGE 4 (20 pts): In overflow4.c, you are really restricted. How on earth are you going to execute any code with that little buffer space? Is there anything in memory that can be of help? (hint, hint) Example: void customerservice(char *arg) { char buf[2353]; strcpy (buf, arg); printf ("Thank you for contacting customer service.\n"); printf ("Please hold for %u minutes while I drop your call\n", (int)strlen(buf)); return; } int main(int argc, char **argv) { if (argc != 2) { printf ("Welcome to xxx.\n"); printf ("Something here (as an argument).\n"); return -1; } customerservice (argv[1]); printf ("Bye \n"); return 0; }