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

How to analyze the principle of CVE-2017-1000405 vulnerability, I believe that many inexperienced people do not know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

1 background of loophole

DirtyCrow is a very famous public vulnerability. This vulnerability, which directly affects millions of users, has been affected by this vulnerability in every Linux version over the past decade, including Android phones, desktops and servers. The first dirty cow loophole was made public in 2016 with the cve number CVE-2016-5195.

Recently, however, the foreign security team Bindecy once again exposed the kernel rights vulnerability called HugeDirty Cow, numbered as CVE-2017-1000405. Servers, desktops, mobile and many other devices that contain the linux kernel (2.6.38 to 4.14) will face serious challenges, and millions of users will be threatened by security. The flaw is due to incomplete patching of the previous kernel privilege vulnerability (cve-2016-5195).

2 loophole analysis

Before analyzing the big dirty cow vulnerabilities, let's review the vulnerability generation process of CVE-2016-5195. The vulnerability is located in the get_user_pages function and get_user_pages in mm/gup.c. When the write system call writes data to the / proc/self/mem file, the kernel will call the get_user_pages function to obtain the address to be written to memory after entering the kernel state.

The specific get_user_pages functions are as follows:

When entering the system kernel, the get_user_pages function is called to cycle through the memory address until the memory mapping requirements are met.

Get_user_pages also calls get_user_pages to get the page table entry of this memory and requires the memory map pointed to by the page table entry to have writeable permissions.

After calling faultin_page for page fault handling, get_user_page calls follow_page_mask for the second time to get the page table entry of this memory. If the page table entry you need to get points to a read-only mapping, the second acquisition will also fail. At this time, the get_user_pages function will call follow_page_mask for the third time to obtain the page table entry of the memory, and the memory map pointed to by the page table entry is no longer required to have writeable permission, which can be obtained successfully. After successful acquisition, the kernel will force a write operation on the read-only memory. The written content is not synchronized to the file. If the virtual memory written is a VM_SHARE mapping, then the mmap can be mapped successfully only if the process has write permission to the file, so it is not ultra vires to synchronize the writes to the file.

The function of mmap is to map the contents of hard disk files to memory. The index file established by closed-chain hash is very suitable for memory mapping using mmap. The address pointer returned by mmap is the first address of the index file in memory, so you can access these contents.

If after the second failure to get the page table item, another thread calls madvice (addr,addrlen,MADV_DONTNEED)

Where addr~addrlen is a read-only memory mapping of the VM_PRIVATE of a read-only file, then the mapped page table entry will be left empty. At this point, if the get_user_pages function calls follow_page_mask for the third time to get the page table entry for that memory. Because this call no longer requires the memory map to have write permission, the kernel no longer performs a COW operation to produce a copy for writing during page fault processing. Therefore, when follow_page_mask is called to obtain the page table entry of this memory for the fourth time after the completion of page fault processing, not only can it be successfully obtained, but also the forced writing after acquisition will also be synchronized to the mapped read-only file, resulting in ultra vires writing of read-only files, resulting in privilege escalation vulnerabilities.

Analysis of loopholes in three dirty cattle

The big dirty cow vulnerability is a new vulnerability based on the repair of the dirty cow vulnerability, which is mainly caused by the problem in the function of large page memory management in the patch of the dirty cow vulnerability.

Memory is managed by blocks, commonly known as pages, a page with 4096 bytes, 1m memory equal to 256pages, 1G memory equal to 356000 pages, and so on. Linux uses large page management, that is, the page table used by 2MB can manage multiple GE memory, while the 1GE page table can manage TB memory. THP system administrators and developers have reduced a lot of the complexity of using oversized pages. Because THP is designed to improve performance, its developers (community and Red Hat developers) have tested and optimized THP in a variety of systems, configurations, programs, and loads. This allows the default settings of THP to improve the performance of most system configurations.

In the patch's code section on the large memory management page, a page can be marked as dirty without the need for a COW loop through the touch_pmd function

This function is called every time follow_page_mask gets get_user_pages and tries to access a large page. It is clear that there is something wrong with this comment and dirty bit is not meaningless now. Especially when using get_user_pages to read a large page, the page is marked as dirty without going through a COW loop, resulting in an error in the logic of can_follow_write_pmd. Once the copied memory page is obtained, the original page can be contaminated twice-the first time it is created, and the second time it is written to dirty bit. This vulnerability can be attempted in a similar way to dirty cow exploitation.

Big Dirty Niu exploit poc address:

Https://github.com/bindecy/HugeDirtyCowPOC

4 reinforcement suggestions

According to the relevant materials, the patch for the dirty cow loophole was made by linus, the founder of linux, but it was still negligent. The impact of the dirty cow vulnerability is from the 2.6.38 kernel after the linux system, and turned on the support for large-page memory management. The official has also given the relevant patches, it is recommended to upgrade the relevant system patches.

After reading the above, have you mastered how to analyze the principle of CVE-2017-1000405 vulnerabilities? 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.