Shulou(Shulou.com)06/01 Report--

How to analyze the vulnerability of XFRM privilege escalation in Linux kernel? I believe many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Background introduction of 0x00

On November 24, 2017, the OSS community disclosed a vulnerability in the Linux kernel Netlink socket subsystem (XFRM) identified by independent security researcher Mohamed Ghannam, vulnerability number CVE-2017-16939.

360CERT after actual verification, confirmed that the vulnerability does exist, but the poc author believes that there are UAF vulnerabilities, there is the possibility of rights, and we believe that there is no UAF, only the use of uninitialized linked list caused by crash (null pointer reference), and the memory used has been initialized, in fact, can not be laid out in advance, can not be further used to achieve the purpose of rights.

Overview of 0x01 vulnerabilities

Netlink is a special socket, which is a way of two-way data transmission between the kernel and users. User-mode applications can use the powerful functions provided by Netlink by using standard socket API, while kernel-mode applications need to use special kernel API to use Netlink.

XFRM is an extensible functional framework introduced by the Linux 2.6 kernel for security processing, which is used to modify packets as they pass through the routing path.

The cause of the vulnerability is that if you do not call xfrm_dump_policy before calling the xfrm_dump_policy_done function, the linked list will not be initialized, resulting in a null pointer reference and a crash. The official fix adds the xfrm_dump_policy_start function to ensure that it is initialized before calling done.

Impact of 0x02 vulnerability attack surface

1. Affect the version

Affect versions between Linux Kernel 2.6.28 and 4.14

Impact version link:

Http://www.securityfocus.com/bid/101954

two。 Repair version

The vulnerability has been resolved as part of the 1137b5e ("ipsec: fix abnormal xfrm policy dump crash" patch) and has been fixed in the 4.14-rc7 version.

0x03 vulnerability details

1. Technical details

In the function static int netlink_dump (struct sock*sk):

(/ net/netlink/af_netlink.c)

In the above code, we can see that when sk- > sk_rcvbuf is less than or equal to sk_rmem_alloc (notice that we can control sk- > sk_rcvbuf through stockpot), the netlink_dump () check fails, it jumps to the end of the function and exits, but the value of cb_running does not change to false.

So when atomic_read (& sk- > sk_rmem_alloc) > = sk- > sk_rcvbuf, cb- > done (cb) should not be called, and nlk- > cb_running should be set to false. Otherwise, in the static voidnetlink_sock_destruct (struct sock * sk) function:

This function is triggered when close (socketfd). This function detects that nlk- > cb_running is not false and calls the done () function, that is, xfrm_dump_policy_done (), resulting in crash.

2. Verification analysis of poc

The execution process in the original author poc is as follows:

(1) do_setsockopt (): change the value of sk- > sk_rcvbuf

(2) send_msg (fd,&p- > msg):

Atomic_read (& sk- > sk_rmem_alloc) = 0 the first time it is sent

Sk_rcvbuf, after sending, sk- > sk_rmem_alloc is accumulated, and the result is after the first send:

Atomic_read (& sk- > sk_rmem_alloc) > = sk- > sk_rcvbuf

(3) send_msg (fd,&p- > msg):

After the second send, atomic_read (& sk- > sk_rmem_alloc) > = sk- > sk_rcvbuf, done () is not called, but the nlk- > cb_running value remains true.

(4) close (fd): call cb- > done (cb) to cause a crash.

According to the above principle, even if you do not call "do_setsockopt ();" to reduce the value of sk- > sk_rcvbuf, as long as you send many times, then when sk- > sk_rmem_alloc accumulates to more than the value of sk- > sk_ rcvbuf, and after send again, "close (fd)" or when the process exits, it will cause crash.

The original poc can also be triggered as follows (without calling do_setsockopt ()):

3. Summary of loophole analysis

Crash cause Analysis:

The ideal flow of the original program is xfrm_dump_policy ()-> xfrm_dump_policy_done ()

Xfrm_dump_policy () checks whether a bi-directional linked list in callback is initialized, and if not, initializes it (empty chain).

When xfrm_dump_policy_done (), the above linked list has been initialized by default, no longer check, read and write directly. As mentioned earlier, multiple send can result in:

Atomic_read (& sk- > sk_rmem_alloc) > = sk- > sk_rcvbuf

Causes xfrm_dump_policy () to be skipped in netlink_dump (), that is, no linked list is initialized, so when close (fd), xfrm_dump_policy_done () manipulates uninitialized memory, resulting in crash.

Then if the memory can be laid out in advance, any address can be written (through the bi-directional linked list del operation). However, whether or not the operation of initializing the linked list is triggered, this piece of memory will be memset (0) before:

Netlink_dump is called after memset (0) in the _ _ netlink_dump_start function. Next, do the sk_rmem_alloc > = sk_rcvbuf test in netlink_dump, and do not go to xfrm_dump_policy after failure. The memory used in the last xfrm_dump_policy_done is the memory of the previous memset (0). This is the absence of the initialization linked list operation (INIT_LIST_HEAD) in the xfrm_dump_policy process, resulting in a null pointer reference.

So this is only the crash (null pointer reference) caused by the uninitialized linked list, and the memory used has been initialized, in fact, can not be laid out in advance, can not be further used to achieve the purpose of lifting weights.

0x04 repair recommendation

It is recommended that all affected users make security updates in a timely manner. The options are as follows:

1. Security updates have been provided in relevant Linux distributions. Please update them in the form of yum or apt-get.

2. For users who customize the kernel, please download the corresponding source code patch for security update.

Patch link:

Https://github.com/torvalds/linux/commit/1137b5e2529a8f5ca8ee709288ecba3e68044df2

After reading the above, do you know how to analyze the XFRM privilege escalation vulnerability in the Linux kernel? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.