Analysis of Pwn2Own 2017 Linux kernel power-Claim vulnerability __linux

0. Foreword

In the 2017 Pwn2Own competition, changting Safety Research Lab (Chaitin) successfully demonstrated the local claim of Ubuntu 16.10 Desktop. This attack took advantage of a memory-Cross-border vulnerability in the Linux kernel IPSec framework (supported from linux2.6), CVE number cve-2017-7184.

As we all know, Linux has a wide range of applications, we often use the Android, Redhat, CentOS, Ubuntu, fedora and so on are using the Linux operating system. After Pwn2Own, Google, Redhat also issued a vulnerability bulletin or patch for the corresponding product (see Resources). Thanks to the Changting Security Research Lab, it is also recommended that the small partners who have not upgraded the server kernel update the kernel to the latest version in time: P

Unlike the usual situation, in order to increase the difficulty of the game, the Pwn2Own competition to use the Linux version opened a number of vulnerability mitigation measures, KASLR, SMEP, SMAP are open by default, in this case, the vulnerability becomes extremely difficult to use, Many of these vulnerabilities may have been defeated only in the face of these mitigation measures.

In addition, it is worth mentioning that the exploit of the vulnerability is extremely high, the Linux kernel in the existence of a very long time. Since triggering this vulnerability requires not only the configuration of kernel data structures, but also the kernel's handling of the carefully constructed packets of the attacker, it is almost impossible to discover this vulnerability using the traditional fuzz approach.

In the end, the Changting Security Research Laboratory successfully exploited this vulnerability to pop up Pwn2Own's first xcalc in the Pwn2Own Arena, and Zdi staff were pleasantly surprised to see it.

Let's take a look at the discovery and utilization of the entire vulnerability.
Introduction to 1.IPSEC protocol

IPSec is a protocol combination that contains Ah, ESP, IKE protocols, and provides authentication and encryption to the packet.

To help better understand the causes of the vulnerabilities, here are a few concepts to briefly describe

(1) SA (security associstion)

The SA is uniquely determined by the three parameters of the SPI, IP, security protocol identifier (AH or ESP). The SA defines the IP addresses, IPSec protocols, cryptographic algorithms, keys, modes, replay windows, and so on for both IPSec parties.

(2) AH (authentication Header)

AH provides data integrity checksum and identity authentication for IP packets, provides playback capability, and verifies the algorithm is specified by SA.

(3) ESP (Encapsulating Security Payload)

ESP provides integrity checking, authentication, and encryption for IP packets. IPSec implementation of the 2.Linux kernel

The IPSec implementation in the Linux kernel is xfrm this framework, and the code for XFRM is mainly under Net/xfrm and Net/ipv4.

The following is the approximate function of the code under/NET/XFRM

XFRM_STATE.C     State Management
XFRM_POLICY.C    xfrm Policy Management
XFRM_ALGO.C      algorithm management
xfrm_hash.c      hash calculation function
XFRM_INPUT.C     Security Path (sec_path) processing,      SA and SP (Security Policy) management for processing incoming IPSec packets xfrm_user.c NetLink interfaces

The code in XFRM_USER.C allows us to send netlink messages to the kernel to invoke the relevant handler to implement the configuration of the SA and SP, which involves processing functions as follows.

Xfrm_dispatch[xfrm_nr_msgtypes] = {[Xfrm_msg_newsa-xfrm_msg_base] = {. doit = Xfrm_add_sa}, [Xfrm_msg_del Sa-xfrm_msg_base] = {. doit = Xfrm_del_sa}, [xfrm_msg_getsa-xfrm_msg_base] = {. doit = Xfrm_get_sa     ,. Dump = Xfrm_dump_sa,. Done = Xfrm_dump_sa_done}, [xfrm_msg_newpolicy-xfrm_msg_base] = {. doit = Xfrm_add_policy  [Xfrm_msg_delpolicy-xfrm_msg_base] = {. doit = xfrm_get_policy}, [xfrm_msg_getpolicy-xfrm_msg_base] = {
	                                   . doit = xfrm_get_policy,. Dump = Xfrm_dump_policy, . Done = Xfrm_dump_policy_done}, [xfrm_msg_allocspi-xfrm_msg_base] = {. doit = Xfrm_alloc_userspi}, [Xfrm_msg_acqu Ire-xfrm_msg_base] = {. doit = xfrm_add_acquire}, [xfrm_msg_expire-xfrm_msg_base] = {. doit = Xfrm_add_sa_ Expire}, [xfrm_msg_updpolicy-xfrm_msg_base] = {. doit = xfrm_add_policy}, [Xfrm_msg_updsa-xfrm_msg_base] = {. doit = Xfrm_add_sa       }, [xfrm_msg_polexpire-xfrm_msg_base] = {. doit = xfrm_add_pol_expire}, [Xfrm_msg_flushsa-xfrm_msg_base]        = {. doit = Xfrm_flush_sa}, [xfrm_msg_flushpolicy-xfrm_msg_base] = {. doit = xfrm_flush_policy}, [Xfrm_msg_newae -Xfrm_msg_base] = {. doit = xfrm_new_ae}, [xfrm_msg_getae-xfrm_msg_base] = {. doit = xfrm_get_ae}, [XF Rm_msg_migrate-xfrm_msg_base] = {. doit = xfrm_do_migrate}, [xfrm_msg_getsadinfo-xfrm_msg_base] = {. doit = X Frm_get_sadinfo}, [xfrm_msg_newspdinfo-xfrm_msg_base] = {. doit = xfrm_set_spdinfo,. nl A_pol = Xfrma_spd_policy,. Nla_max = Xfrma_spd_max}, [xfrm_msg_getspdinfo-xfrm_msg_base] = {. doit = XF
 Rm_get_spdinfo},};

Here's a brief description of the functions of several of these functions:

Xfrm_add_sa

Creates a new SA and can specify the associated attr, in the kernel, a xfrm_state structure to represent an SA.

Xfrm_del_sa

Deletes an SA, or deletes a specified xfrm_state.

Xfrm_new_ae

Updates the contents of the specified Xfrm_state structure based on the incoming parameters.

Xfrm_get_ae

Based on the incoming parameters, the query specifies the contents of the xfrm_state structure, including attr. 3. The cause of the loophole

When we send a message of a XFRM_MSG_NEWSA type, we can call the XFRM_ADD_SA function to create a new SA, and a new xfrm_state will also be created. In the kernel, the SA is actually represented using the xfrm_state structure.

If you use Xfrma_replay_esn_val this attr in NetLink messages, a REPLAY_STATE_ESN structure is also created. Its structure is shown below, and you can see that it contains a bitmap, the length of which is dynamically identified by Bmp_len this member variable.

struct XFRM_REPLAY_STATE_ESN {
    unsigned int bmp_len;
    __u32   oseq;
    __u32   seq;
    __u32   Oseq_hi;
    __u32   Seq_hi;
    __u32   Replay_window;
    __u32   bmp[0];

The kernel's inspection of this structure is mainly in the following ways:

First, the XFRM_ADD_SA function calls Verify_replay to check the incoming REPLAY_STATE_ESN structure when it calls Verify_newsa_info to check data passed in from user state.

static inline int verify_replay (struct xfrm_usersa_info *p, struct nlattr **attrs) {struct nlattr *rt
	= attr S[xfrma_replay_esn_val];
	struct XFRM_REPLAY_STATE_ESN *rs;

	if (P->flags & xfrm_state_esn) {
		if (!rt)
			return-einval;

		rs = nla_data (RT);

		if (Rs->bmp_len > Xfrma_replay_esn_max/sizeof (rs->bmp[0))/8
			return-einval;

		if (Nla_len (RT) < Xfrm_replay_state_esn_len (RS) &&
		    Nla_len (RT)!= sizeof (*RS))
			Return-einval;
	}

	if (!rt) return
		0;

	/* As only ESP and AH support ESN feature. */
	if ((P->id.proto!= ipproto_esp) && (P->id.proto!= ipproto_ah))
		Return-einval;

	if (P->replay_window!= 0)
		return-einval;

	return 0;
}

This function requires that the bmp_len of the REPLAY_STATE_ESN structure not exceed the maximum limit Xfrma_replay_esn_max.

In addition, in the process of creating a xfrm_state, if you check that there is a XFRM_REPLAY_STATE_ESN structure in the member, the check in the following function is executed.

int Xfrm_init_replay (struct xfrm_state *x) {struct XFRM_REPLAY_STATE_ESN *replay_esn
	= x->replay_esn;

	if (REPLAY_ESN) {
		if (Replay_esn->replay_window >
		    replay_esn->bmp_len * sizeof (__U32) * 8) <----- Check Replay_window
			return-einval;

		if (X->props.flags & xfrm_state_esn) {
			if (Replay_esn->replay_window = 0)
				return-einval;
			X->REPL = &xfrm_replay_esn;
		} else
			X->repl = &xfrm_replay_bmp;
	} else
		x->repl = &xfrm_replay_legacy;

	return 0;
}

This function ensures that the Replay_window is not larger than the length of the bitmap, otherwise the function exits directly.

Let's take a look at the Xfrm_new_ae function, which first resolves several attr in the user state, and then finds the specified xfrm_state based on the hash value of the SPI and IP, and then xfrm_replay_verify_len the incoming Replay_ STATE_ESN structure to do a check, through which will call the Xfrm_update_ae_params function to update the corresponding xfrm_state structure. Let's take a look at the Xfrm_replay_verify_len function here.

static inline int Xfrm_replay_verify_len (struct xfrm_replay_state_esn *replay_esn, struct nlattr *rp
					 )
{
	struct XFRM_REPLAY_STATE_ESN *up;
	int Ulen;