[Expert column] Anti-buffer overflow Technology in Android

BKJIA: This article describes in detail the ins and outs of the anti-buffer overflow Technology in Android.

1. What is ASLR?

ASLRAddress space layout randomization) is a security protection technology for buffer overflow. It randomizes linear zone la S such as heap, stack, and shared library ing, by increasing the difficulty for attackers to predict the target address, attackers are prevented from directly locating the attack code to prevent overflow attacks. In general, hackers exploit the fact that a specific function or library is located in a specific memory location to call the function to launch an attack when a heap or other memory error occurs. ASLR can avoid this situation because it ensures that the code of the system and application will not appear in the same storage location each time it is loaded. Apple's iOS system has supported the ASLR technology since iOS 4.3. Although Comex released the "iPhone jailbreak" software in January July, this defense has been overcome. Android has applied the ASLR Technology in 4.0.

According to research, ASLR can effectively reduce the success rate of buffer overflow attacks. Currently, mainstream operating systems such as Linux, FreeBSD, and Windows have adopted this technology.

2. Principles of buffer overflow attacks

Buffer overflow is a very common and dangerous vulnerability, which is widely used in various operating systems and applications. Buffer overflow attacks can cause program running failure, system downtime, restart, and other consequences. More seriously, you can use it to execute unauthorized commands, or even obtain SYSTEM privileges for various illegal operations.

Buffer overflow figure 1) refers to the data that exceeds the buffer's capacity overflow when the computer fills the number of data digits in the buffer zone, ideally, the program checks the Data Length and does not allow the input to exceed the buffer length. However, most programs assume that the Data Length always matches the allocated storage space, this poses a hidden danger to buffer overflow. the buffer used by the operating system is also called "stack ". commands are temporarily stored in the "stack" among various operation processes, and "stack" also causes buffer overflow.

In the current network and distributed system security, more than 50% of the widely used vulnerabilities are buffer overflow. The most famous example is the worm exploiting the fingerd vulnerability in 1988. In buffer overflow, stack overflow is the most dangerous because intruders can use stack overflow to change the address of the returned program when the function returns and redirect it to any address, one of the hazards is that a program crashes, causing a denial of service. The other is to jump to and execute a piece of malicious code, such as getting a shell and then doing whatever you want.

The most famous buffer overflow attack in history may be the attack code carried by Morris Worm in November 2, 1988. The Internet worm exploits the buffer overflow vulnerability of the fingerd program, causing great harm to users. More and more buffer overflow vulnerabilities have been discovered since then. From common service programs such as bind, wu-ftpd, telnetd, and apache to applications provided by software vendors such as Microsoft and Oracle, there seems to be a buffer overflow vulnerability that will never be completed.

Figure 1 Buffer Overflow Attack Diagram

3. A simple comparison example after applying ASLR

The following uses a typical example to show the effects before and after ASLR:

C source code:

 
 

  
  
#include <stdlib.h>  
  
  
#include <unistd.h>  
  
  
main()  
  
  
 {  
  
  
     char *i;  
  
  
     char buff[20];  
  
  
    i=malloc(20);  
  
  
     sleep(1000);  
  
  
     free(i);  
  
  
 }  
  
  
#ps -aux|grep test  
  
  
 Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html  
  
  
 aslr_test        8731  0.0  0.0   1632   332 pts/0    S+   18:49   0:00 ./test  
  
  
 aslr_test        8766  0.0  0.0   2884   748 pts/1    R+   18:49   0:00 grep test  
  
  
 aslr_test@aslr_test-laptop:~$ cat /proc/8731/maps  
  
  
 08048000-08049000 r-xp 00000000 08:01 2256782    /home/aslr_test/Desktop/test  
  
  
 08049000-0804a000 rw-p 00000000 08:01 2256782    /home/aslr_test/Desktop/test  
  
  
 0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]  
  
  
 b7e60000-b7e61000 rw-p b7e60000 00:00 0  
  
  
 b7e61000-b7f9c000 r-xp 00000000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
  
  
 b7f9c000-b7f9d000 r--p 0013b000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
  
  
 b7f9d000-b7f9f000 rw-p 0013c000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
  
  
 b7f9f000-b7fa2000 rw-p b7f9f000 00:00 0  
  
  
 b7fae000-b7fb0000 rw-p b7fae000 00:00 0  
  
  
 b7fb0000-b7fc9000 r-xp 00000000 08:01 12195      /lib/ld-2.5.so  
  
  
 b7fc9000-b7fcb000 rw-p 00019000 08:01 12195      /lib/ld-2.5.so  
  
  
 bfe86000-bfe9c000 rw-p bfe86000 00:00 0          [stack]  
  
  
 ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]  
  
  
#ps -aux|grep test  
  
  
 Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html  
  
  
 aslr_test        8781  0.0  0.0   1632   332 pts/0    S+   18:49   0:00 ./test  
  
  
 aslr_test        8785  0.0  0.0   2884   748 pts/1    R+   18:49   0:00 grep test  
  
  
 aslr_test@aslr_test-laptop:~$ cat /proc/8781/maps  
  
  
 08048000-08049000 r-xp 00000000 08:01 2256782    /home/aslr_test/Desktop/test  
  
  
 08049000-0804a000 rw-p 00000000 08:01 2256782    /home/aslr_test/Desktop/test  
  
  
 0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]  
  
  
 b7e1e000-b7e1f000 rw-p b7e1e000 00:00 0  
  
  
 b7e1f000-b7f5a000 r-xp 00000000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
  
  
 b7f5a000-b7f5b000 r--p 0013b000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
  
  
 b7f5b000-b7f5d000 rw-p 0013c000 08:01 12116      /lib/tls/i686/cmov/libc-2.5.so  
  
  
 b7f5d000-b7f60000 rw-p b7f5d000 00:00 0  
  
  
 b7f6c000-b7f6e000 rw-p b7f6c000 00:00 0  
  
  
 b7f6e000-b7f87000 r-xp 00000000 08:01 12195      /lib/ld-2.5.so  
  
  
 b7f87000-b7f89000 rw-p 00019000 08:01 12195      /lib/ld-2.5.so  
  
  
 bfe23000-bfe39000 rw-p bfe23000 00:00 0          [stack]  
  
  
 ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]  
 
 

By comparing the process information under/proc after two operations, we can find that the address space mapped to the process stack and the shared library has changed significantly, this greatly reduces the success rate of predicting the shellcode address by using the esp value. There was an article in Phrack59 about how to use the return-into-libc method to break through ASLR protection, but there are large restrictions, an article in milw0rm also introduced the method of turning to execute shellcode by searching the jmp % esp command in the linux-gate.so.1, but since the esp value to be restored by the current compiler is saved in the stack, therefore, you cannot continue using it. In general, the ASLR technology can ensure the security of Android code and operation.