DOC PREVIEW
GT ECE 4112 - ECE 4112 Lab 4: Buffer Overflows

This preview shows page 1-2-23-24 out of 24 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

BackgroundLab ScenarioSection III – Common VulnerabilitiesRecord your successful buffer size and offset values.Section V – Libsafe – A Stack Buffer Overflow Preventive MeasureThe Stack RegionOverflowing a BufferUnderstanding Return Pointer RedirectionShellcodeWriting an Exploit6) exploit2 successful buffer size and offset or ten attempts and reasoning:Section III – Common VulnerabilitiesScreenshot of crashing WindowsXPGroup Number:______Member Names: ____________ _____________ ECE 4112 Lab 4:Buffer OverflowsLast Edited: 10/28/04Date Issued: 9/14/04Due Date: 9/21/04Lab GoalThis lab will introduce you to the memory stack used in computer processes and demonstrate how to overflow memory buffers in order to exploit application security flaws. You will then execute several buffer overflow attacks against your Linux and Windows XP machines in order to gain root or administrative access using application vulnerabilities.Pre-LabCarefully read the entire article Smashing the Stack for fun and profit by Aleph One. It is essential that you have a thorough understanding of this article before you attempt these attacks, and although the author’s computer system differs from ours, it will be useful as a reference during the lab. After completion of the lab, turn in answers to the questions found at the end this document.BackgroundAlthough computer programs are frequently written in English-based user-friendly languages such as C, they must be compiled to an assembly language built for the machine on which they will be executed. The assembly language has much fewer commands than C, and these commands are much less varying in structure and less obvious semantically. Commands are stored in memory so that each is referenced by its location in memory rather than its line number in the code. Commands are executed sequentially, and functions are executed by jumping to a particular memory location, continuing sequential execution, and jumping back at the end of the function. A tutorial describing conversion from C code to x86 assembly can be found at:http://linuxgazette.net/issue94/ramankutty.html When a computer process is executed, it gains access to a portion of the computer’s memory system. In the lower set of addresses of the allocated memory, the compiled assembly instruction set is placed so that the computer can execute these instructions directly from memory. This part of memory is generally flagged as read-only, and attempting to modify it results in a segmentation fault. Segmentation faults can occur for other reasons as well, such as if an invalid instruction is executed. At a higher portion of 1addresses, variables are allocated and stored. Whenever a process saves some data to memory (e.g. int a=4), they are placed in this region. Finally, the highest portion of addresses contains the memory stack. The stack helps coordinate the hierarchical execution of functions within applications. When a function iscalled, a variable known as the frame pointer is pushed onto the stack, which references the memory locations of variables local to the function. Next, since a function is executedby a jump from a different location in memory, a return address is pushed onto the stack so that the computer knows where in memory to return once the function has been completed. Finally, when a function is passed variables (e.g. myfunc(a,b,c)) these variables are also placed on the stack. Theoretically, stack manipulation should be accomplished entirely by the process, which allocates and sets pointers and variables at appropriate stages of execution, such as function calls. The key to buffer overflow attacks is to maliciously manipulate the data in the stack. By changing the return pointer, for example, it is possible for the process to jump to a memory location containing user data rather than the correct location in the instruction set. If the user data is crafted to include malicious assembly commands, such as a backdoor, these will be executed. Finally, we’ll be taking a look at heap-overflows. Although heap overflows can be exploited just as easily as stack overflows, they’re much less known. System administrators often implement patches and precautions to prevent stack overflows but leave the heaps completely open to attacks! Although we won’t be doing any exercises in the lab about heap overflows, more information about it has been included as an appendix(Appendix B). Lab ScenarioFor most of the lab, you will be using only your RedHat 8.0 host machine. You will need to use your Redhat 7.2 virtual machine for remote buffer overflow attacks and you will use your Windows XP virtual machine in an exercise to see how contemporary attacks compromise windows systems.2Section I – Experimentation with “Smashing the Stack for fun and profit” by Aleph OneConnect to Network Attached Storage, and copy the file Lab4/stacksmash.tgz to your RedHat8.0 machine. Decompress it with the command:tar zxvf stacksmash.tgzEnter the stacksmash directory, and type make to compile. To recompile during the rest ofthis section, follow the instructions specific to the exercise or simply take make again. Exercise 1: The Stack RegionSource file: example1.cFor this section, the make file has compiled the source to assembly code using the command:gcc –S –o example1.s example1.cOpen the original c file and the assembly (.s) file in text editors and observe how the assembly code maps to the c source. The assembly code will be slightly different thanwhat appears in the paper, because Aleph One’s computer is different from ours. Draw a diagram of the process memory at the time that function is called.Exercise 2: Buffer OverflowsSource file: example2.cThe make file has compiled our second example using the commandgcc –o example2 example2.cObserve the source code then execute the binary by typing ./example2What are your results? Why?Exercise 3: Return Pointer RedirectionSource file: example 3.c3Observe the source file. This exploit attempts first to create a pointer (ret) to the function return address, then modify the return address value (*ret). At the end of the function call, the function will return to an incorrect address. The purpose of this exercise is to attempt to redirect the pointer and skip the “x=1” line, so that the example prints “0.” Unfortunately, because your memory stack is different than Aleph One’s, it is not successful. Read the paper carefully and try to understand


View Full Document

GT ECE 4112 - ECE 4112 Lab 4: Buffer Overflows

Documents in this Course
Firewalls

Firewalls

40 pages

Firewalls

Firewalls

126 pages

Load more
Download ECE 4112 Lab 4: Buffer Overflows
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view ECE 4112 Lab 4: Buffer Overflows and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view ECE 4112 Lab 4: Buffer Overflows 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?