[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    [FD] =?utf-8?q?SSD_Advisory_=E2=80=93_Linux_Kernel_XFRM_Privilege?= =?utf-8?q?_Escalation?=
From:       Maor Shwartz <maors () beyondsecurity ! com>
Date:       2017-11-23 8:53:52
Message-ID: CAAnZqX-+-3VxjnMnOpVamB1EZLCFO86KRKmbFptAAbJWmXR7OA () mail ! gmail ! com
[Download RAW message or body]

SSD Advisory – Linux Kernel XFRM Privilege Escalation


Full report: https://blogs.securiteam.com/index.php/archives/3535
Twitter: @SecuriTeam_SSD
Weibo: SecuriTeam_SSD

Vulnerability Summary
The following advisory describes a Use-after-free vulnerability found in
Linux kernel that can lead to privilege escalation. The vulnerability found
in Netlink socket subsystem – XFRM.

Netlink is used to transfer information between the kernel and user-space
processes. It consists of a standard sockets-based interface for user space
processes and an internal kernel API for kernel modules.

Credit
An independent security researcher, Mohamed Ghannam, has reported this
vulnerability to Beyond Security's SecuriTeam Secure Disclosure program

Vendor response
The vulnerability has been addressed as part of 1137b5e ("ipsec: Fix
aborted xfrm policy dump crash")

Vulnerability details
An unprivileged user can change Netlink socket subsystem – XFRM value
sk->sk_rcvbuf (sk == struct sock object).

The value can be changed into specific range via setsockopt(SO_RCVBUF).
sk_rcvbuf is the total number of bytes of a buffer receiving data via
recvmsg/recv/read.

The sk_rcvbuf value is how many bytes the kernel should allocate for the
skb (struct sk_buff objects).

skb->trusize is a variable which keep track of how many bytes of memory are
consumed, in order to not wasting and manage memory, the kernel can handle
the skb size at run time.

For example, if we allocate a large socket buffer (skb) and we only
received 1-byte packet size, the kernel will adjust this by calling
skb_set_owner_r.

By calling skb_set_owner_r the sk->sk_rmem_alloc (refers to an atomic
variable sk->sk_backlog.rmem_alloc) is modified.

When we create a XFRM netlink socket, xfrm_dump_policy is called, when we
close the socket xfrm_dump_policy_done is called.

xfrm_dump_policy_done is called whenever cb_running for netlink_sock object
is true.

The xfrm_dump_policy_done tries to clean-up a xfrm walk entry which is
managed by netlink_callback object.

When netlink_skb_set_owner_r is called (like skb_set_owner_r) it updates
the sk_rmem_alloc.

netlink_dump():

In above snippet we can see that netlink_dump() check fails when
sk->sk_rcvbuf is smaller than sk_rmem_alloc (notice that we can control
sk->sk_rcvbuf via stockpot).

When this condition fails, it jumps to the end of a function and quit with
failure and the value of cb_running doesn't changed to false.

nlk->cb_running is true, thus xfrm_dump_policy_done() is being called.

nlk->cb.done points to xfrm_dump_policy_done, it worth noting that this
function handles a doubly linked list, so if we can tweak this
vulnerability to reference a controlled buffer, we could have a read/write
what/where primitive.



--
Thanks
Maor Shwartz
Beyond Security
GPG Key ID: 6D273779F52A9FC2

["Linux4-1024x424.jpg" (image/jpeg)]
["Linux3-1024x86.jpg" (image/jpeg)]
["Linux2-1024x225.jpg" (image/jpeg)]
["Linux1-1024x101.jpg" (image/jpeg)]
["=?UTF-8?Q?SSD_Advisory_=E2=80=93_Linux_Kernel_XFRM_Privilege_Escalation_?=
	=?UTF-8?Q?=E2=80=93_SecuriTeam_Blogs=2Epdf?=" (application/pdf)]

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[prev in list] [next in list] [prev in thread] [next in thread]