程序代写｜CSE 361 Fall 2022 Lab Assignment L3: Understanding Buffer Overflow Bugs

这是一篇来自澳洲的关于实验室分配L3：理解缓冲区溢出错误分配的程序代写

1 Introduction

This assignment involves generating a total of fifive attacks on two programs having different security vulnerabilities. Outcomes you will gain from this lab include:

You will learn different ways that attackers can exploit security vulnerabilities when programs do not safeguard themselves well enough against buffer overflflows.

Through this, you will get a better understanding of how to write programs that are more secure, as well as some of the features provided by compilers and operating systems to make programs less vulnerable.

You will gain a deeper understanding of the stack and parameter-passing mechanisms of x86-64 machine code.

You will gain a deeper understanding of how x86-64 instructions are encoded.
You will gain more experience with debugging tools such as GDB and OBJDUMP.

In this lab, you will gain fifirsthand experience with methods used to exploit security weaknesses in operating systems and network servers. Our purpose is to help you learn about the runtime operation of programs and to understand the nature of these security weaknesses so that you can avoid them when you write system code. We do not condone the use of any other form of attack to gain unauthorized access to any system resources.

Note: You will want to study Sections 3.10.3 and 3.10.4 of the CS:APP3e book as reference material for this lab.

Another Note: Make sure you carefully read both appendices before you start! You will need to use the tools described in both appendices to complete the attack.

2 Logistics

As usual, this is an individual project. You will generate attacks for target programs that are custom generated for you.

2.1 Getting Files

Like in lab 2, you need to get on the engineering school network to obtain your fifiles (see instructions on how to do that from lab 2). Once you are on the engineering network, you can obtain your fifiles by pointing your Web browser at:

http://shell2.cec.wustl.edu:18213

The server will build your fifiles and return them to your browser in a tar fifile called targetk.tar, where k is the unique number of your target programs.

Note: It takes a few seconds to build and download your target, so please be patient.

Save the targetk.tar fifile in a (protected) Linux directory in which you plan to do your work. Then give the command: tar -xvf targetk.tar. This will extract a directory targetk containing the fifiles described below.

You should only download one set of fifiles. If for some reason you download multiple targets, choose one target to work on and delete the rest.

Warning: If you expand your targetk.tar on a PC, by using a utility such as Winzip, or letting your browser do the extraction, you’ll risk resetting permission bits on the executable fifiles.

The fifiles in targetk include:

README.txt: A fifile describing the contents of the directory

ctarget: An executable program vulnerable to code-injection attacks

rtarget: An executable program vulnerable to return-oriented-programming attacks

cookie.txt: An 8-digit hex code that you will use as a unique identififier in your attacks.

farm.c: The source code of your target’s “gadget farm,” which you will use in generating return-oriented programming attacks.

hex2raw: A utility to generate attack strings.

2.2 Important Points

Here is a summary of some important rules regarding valid solutions for this lab. These points will not make much sense when you read this document for the fifirst time. They are presented here as a central reference of rules once you get started.

You must do the assignment on one of the class machines, i.e., linuxlab<N>.seas.wustl.edu for <N> = 001 — 012.

Technically, you can work on fifiguring out the solutions to the lab on any Linux machine that is x86-64, but you must submit your solution on one of the linux lab machines (i.e., run the program and feed it the correct input string).

In the following instructions, we will assume that you have copied the fifiles to a protected local directory accessible via one of the linuxlab machines, and that you are executing the programs in that local directory.

Your solutions may not use attacks to circumvent the validation code in the programs. Specififically,any address you incorporate into an attack string for use by a ret instruction should be to one of the following destinations:

– The addresses for functions touch1, touch2, or touch3.

– The address of your injected code

– The address of one of your gadgets from the gadget farm.

You may only construct gadgets from fifile rtarget with addresses ranging between those for functions start_farm and end_farm.

3 Target Programs

Both CTARGET and RTARGET read strings from standard input. They do so with the function getbuf defifined below:

1 unsigned getbuf()

2 {

char buf[BUFFER_SIZE];

Gets(buf);

return 1;

6 }

The function Gets is similar to the standard library function gets—it reads a string from standard input (terminated by ‘\n’ or end-of-fifile) and stores it (along with a null terminator) at the specifified destination.

In this code, you can see that the destination is an array buf, declared as having BUFFER_SIZE bytes. At the time your targets were generated, BUFFER_SIZE was a compile-time constant specifific to your version of the programs.

Functions Gets() and gets() have no way to determine whether their destination buffers are large enough to store the string they read. They simply copy sequences of bytes, possibly overrunning the bounds of the storage allocated at the destinations.

If the string typed by the user and read by getbuf is suffificiently short, it is clear that getbuf will return 1, as shown by the following execution examples:

unix> ./ctarget

Cookie: 0x1a7dd803

Type string: Keep it short!

No exploit. Getbuf returned 0x1

Normal return

Typically an error occurs if you type a long string:

unix> ./ctarget

Cookie: 0x1a7dd803

Type string: This is not a very interesting string, but it has the property …

Ouch!: You caused a segmentation fault!

Better luck next time

(Note that the value of the cookie shown will differ from yours.) Program RTARGET will have the same behavior. As the error message indicates, overrunning the buffer typically causes the program state to be corrupted, leading to a memory access error. Your task is to be more clever with the strings you feed CTARGET and RTARGET so that they do more interesting things. These are called exploit strings.

Both CTARGET and RTARGET take several different command line arguments:

-h: Print list of possible command line arguments

-q: Don’t send results to the grading server

-i FILE: Supply input from a fifile, rather than from standard input

Your exploit strings will typically contain byte values that do not correspond to the ASCII values for printing characters. The program HEX2RAW will enable you to generate these raw strings. See Appendix A for more information on how to use HEX2RAW.

Important points:

Your exploit string must not contain byte value 0x0a at any intermediate position, since this is the ASCII code for newline (‘\n’). When Gets encounters this byte, it will assume you intended to terminate the string.

HEX2RAW expects two-digit hex values separated by one or more white spaces. So if you want to create a byte with a hex value of 0, you need to write it as 00. To create the word 0xdeadbeef you should pass “ef be ad de” to HEX2RAW (note the reversal required for little-endian byte ordering).

When you have correctly solved one of the levels, your target program will automatically send a notifification to the grading server. For example:

unix> ./hex2raw < ctarget.l2.txt | ./ctarget

Cookie: 0x1a7dd803

程序辅导定制C/C++/JAVA/安卓/PYTHON/留学生/PHP/APP开发/MATLAB