Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to carry out the early warning analysis of local rights raising vulnerabilities in the Linux kernel. Many people may not know much about it. In order to make you understand better, the editor has summarized the following for you. I hope you can get something according to this article.

First, the background of loopholes

Recently, a commit patch has been released in Linux git, which corresponds to a local rights vulnerability, CVE-2019-8912, which has a wide range of impact. According to the commit information in git, the vulnerability appears in the af_alg_release function in kernel 'crypto/af_alg.c', which can be triggered by the sockfs_setattr function. The vulnerability type is use after free, which can lead to privilege escalation for local code execution.

2. Vulnerability-affected version Linux 2.6 ~ linux 4.20.11Red Hat Enterprise Linux 7 Magi package: kernel-altDebian,Release:Jessie,Version:3.16.56-1 Debian 8u1Debian Magic ReleaseJessie (security), Version:3.16.56-1Debian Debian DifferentReleaseVersionVere 4.9.144-3DebianParticipationReleaseWirlDebian (security), Version:4.9.110-3Debide9u6DebianReleaseVersionVersionRemoster16-1DebianPartition 4.19.16-1ReleaseVersionVersionVersionRemotor4.19.20-1 third, introduction to Linux Crypto module.

Linux kernel has introduced encryption mechanism from version 2.5 to provide encryption functions for the kernel. The applications include hardware encryption device driver, kernel code signature, hardware random number generator, file system encryption and so on. Since version 2.6.6, the kernel source code provides rich support for cryptographic algorithms, and encryption algorithms can be programmed into the kernel as modules by configuring compilation options. The kernel compilation configuration is shown in the following figure:

However, the API interface provided by this encryption function can only be used in the kernel layer and cannot be called in the user layer. In 2010, a maintainer submitted a CrypatoAPI user interface to the Linux Crypto maintenance team, which is similar to netlink and communicates based on socket, making it easy for the user layer to access the kernel encryption subsystem. The function implementation code is in the file crypto/af_alg.c.

Fourth, the principle and source of loopholes

The vulnerability lies in the af_alg_release () function in the crypto module. The af_alg_release () function does not empty the object when it releases the object. The corresponding commit:9060cb719e61b685ec0102574e10337fa5f445ea patch code is as follows, with a line of code added to the patch: sock- > sk = NULL;.

Before the patch is added, if the sock- > sk reference count is 1, when sock_put () is called to release, it is returned directly, resulting in a sock- > sk dangling pointer.

In order to analyze the causes and consequences of this vulnerability, first analyze the relevant socket code. For each newly created socket,Linux kernel, a new inode is created in sockfs. The Sockfs_* series of functions are used to manipulate the sockfs file system. The Sockfs_setattr () function sets the properties of the socket file. The sockfs_setattr () function in the net/socket.c file will use the sock- > sk object.

According to the details of the submitted commit:9060cb719e61b685ec0102574e10337fa5f445ea, before the vulnerability is disclosed, Linux has fixed the conditional race vulnerability between sock_close () and sockfs_setattr (). The corresponding commit is 6d8c50dcb029872b298eea68cc6209c866fd3e14. Let's take a look at the patch in the sockfs_setattr () function. The patch code is as follows:

Line 544 first determines whether sock- > sk is empty, and if not, line 545 assigns the iattr- > ia_uid passed in to the user layer as sock- > sk- > sk_uid. Then look at the patch in the sock_close () function. The patch code is as follows:

Line 1186, replaced with the new function _ _ sock_release (), which has an extra argument, inode. The _ _ sock_release () function is implemented as follows:

Line 601, determine the inode, if it is not empty, then call the inode_lock () function to lock it. In fact, the inode itself corresponds to the socket object to be released. Line 603, call the release () function in ops for the release operation. The release () function in this ops is just a function pointer that ultimately depends on which socket type the user registers. Line 604, determine again whether inode is empty, and if not, unlock it. By locking the inode, other operations are prevented when the socket object is released.

As you can see from the details provided by commit:6d8c50dcb029872b298eea68cc6209c866fd3e14, the conditional competition between the sock_close () function and the sockfs_setattr () function can be triggered by the user-level fchownat () function. According to the man manual, this function is used to set file properties, such as uid and gid, and the corresponding sockfs_setattr () function in the kernel, as shown in the following figure:

As described in the details, this function does not maintain the reference count of the file fd, which is also the reason for the existence of conditional competition. According to the previous article, the sockfs_setattr () function actually operates on the sock- > sk object by setting UID.

If you continue to go back, the details provided by commit:86741ec25462e4c8cdce6df2f41ead05568c7d5e can tell the whole story of UID. The patch was submitted in 2016. Because the structure structsock in the socket protocol is mapped to the sockets of the user layer most of the time, the kernel structure of sockets is structsocket. For ease of operation, a key function is added to simplify the matching of UID in struct socket by adding a sk_uid field to struct sock. As shown in the following figure:

From this, we can see that the conditional competition between sock_close () and sockfs_setattr has been fixed, because the af_alg_release () function in crypto/af_alg.c did not empty the released sock- > sk in time, resulting in all the previous security patches invalid.

V. Safety recommendations

At present, the patch for this vulnerability has been given, please upgrade to the latest version in time.

Https://github.com/torvalds/linux/commit/9060cb719e61b685ec0102574e10337fa5f445ea

After reading the above, do you have any further understanding of how to conduct Linux kernel local privilege vulnerability early warning analysis? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.