Thursday, 2 March 2017

A vulnerability in the Linux kernel that allows you to gain root access





In the Linux kernel found a vulnerability ( the CVE-2017-6074 ), which allows an unprivileged local user to execute code with root privileges. The problem is resolved on February 17, and is manifested in all nuclei with support for DCCP, since 2.6.14 (October 2005) and up to release 4.9.11. 

It should be noted that the vulnerabilities identified in the implementation of DCCP is not the first time, similar critical problems were detected in 2008 and 2014 , respectively.


Discovered a vulnerability researcher announced the creation of a working exploit, which will be published in a few days, as soon as the major distributions has released an update to fix the problem. Package upgrades until released for RHEL and of Ubuntu . The problem remains uncorrected in the Debian , the Fedora , openSUSE and Debian).



The vulnerability is manifested only in the cores collected from CONFIG_IP_DCCP option that almost all distributions by default. If DCCP collected in the form of a kernel module as a bypass to protect the way you can prevent the loading of this module, which is normally loaded automatically:

echo "install dccp / bin / true" >> /etc/modprobe.d/disable-dccp.conf




Vulnerability found Andrey Konovalov when fuzzing-test kernel with the packet syzkaller . The problem is caused by the release of a double memory block in the function dccp_rcv_state_process (net / dccp / input.c) and can be exploited when processing a specially designed package DCCP_PKT_REQUEST, transmitted through the socket, open from IPV6_RECVPKTINFO option. Under normal conditions, a dedicated packet buffer dccp_skb exempt from challenge __kfree_skb dccp_rcv_state_process function on success dccp_v6_conn_request function.


If there IPV6_RECVPKTINFO flag buffer address dccp_skb additionally stored in the structure ireq-> pktopts and exhibit use flag buffer. Cleaning function in dccp_rcv_state_process called regardless of the flag that can be used to manipulate the data after their release (use-after-free). In particular, an attacker could overwrite arbitrary data contents of another object in the kernel, using "techniques the heap spraying ".

 If the rewritten object contains pointers to functions that are called in the course of work, the attacker can achieve implementation of the code at the kernel level. 

No comments:

Post a Comment