Shulou(Shulou.com)06/01 Report--

This article shows you how to carry out CVE-2017-16943-Exim-UAF vulnerability analysis, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

Background introduction of 0x00

Exim is an open source software based on GPL protocol developed by Cambridge University, which is mainly used to connect to the message transfer Agent (MTA) server of the Internet Unix system.

On November 25, 2017, Exim officially fixed a vulnerability in use-after-free. Meh, a researcher at Taiwan security company DEVCORE, found that the CVE number was CVE-2017-16943 and published a POC, but according to our analysis, the POC must turn on the dkim in the configuration file to control the EIP and cause the process to crash.

On December 11, 2017, Meh announced the details of the vulnerability and the POC under the default configuration on the official website of DEVCORE.

This is verified by 360 CERT, which proves that it can cause remote code execution, which has a wide range of influence and serious harm.

Impact of 0x01 vulnerability attack surface

1. Influence surface

According to the 360CERT network-wide asset retrieval platform, the search results as of December 15, 2017 show that there are more than 1 million servers running Exim around the world. The global impact distribution map is as follows:

2. Affect the version

The vulnerability affects versions 4.88 and 4.89 of the enabled chunk settings

3. Repair version

CERT recommends that users download the official fix in time, turn off the chunk setting or update to version 4.90.

0x02 vulnerability details

1. Enable control rip in dkim configuration

Exim manages a total of three heaps, defined as global variables of enumerated types:

POOL_MAIN: represents the main allocated heap block, which can be released, and message processing is allocated in this heap pool.

POOL_PERM: indicates that the allocated memory is permanent and will not be released until the end of the process. Save some information that needs to be shared, such as configuration information, host information, change store_pool to POOL_PERM before using this heap pool allocation, and then call store_get ().

POOL_SEARCH: saves search data, which is used in search_tidyup, search_open, internal_search_find functions.

Exim reads messages in a loop and allocates memory dynamically. Functions that request memory include: expand_string (), store_get (), string_xxx (), and store_get_perm () uses perm pool.

Commenting "control = dkim_disable_verify" in the configuration file / usr/exim/configure can trigger a process crash, which in turn controls rip. The reasons are as follows:

Whether to enable dkim is determined in the receive_msg function. If enabled, the dkim_exim_verify_init function is entered:

Apply for memory in perm pool in the dkim_exim_verify_init function:

So that a piece of memory is allocated in the heap without changing the value in current_block [0]. Later, when processing messages, the heap block will be allocated in main pool and a heap block of 0x2010 size will be allocated. After release, because of the heap block allocated by perm pool before, the released heap block is not merged with top chunk and becomes a unsorted bin. At this time, fd and bk point to the main arena area. After entering the store extend again, the pointer to the main arena is obtained through the store_get, and then the memcpy writes to the main arena, the subsequent free operation will cause a crash, and the RIP will become populated data.

The details are as follows:

two。 Control rip under default configuration

After devcore released the details, we analyzed how to control rip in the default configuration. In fact, the principle is similar to enabling dkim configuration. You need to allocate a heap block in use before top_chunk to prevent the later released heap block from merging with top_chunk. The author's poc uses DATA to send a large enough data to expand the heap block. After several cycles, the previous heap block is released and becomes a large unsorted bin block for subsequent allocation. At this point, there is a heap block in use before top_chunk, and then use the BDAT command to control the rip.

The specific process for controlling rip is as follows:

Verification of 0x03 vulnerability exploitation

We write exp according to meh's poc and ideas, and execute the attack code by controlling rip to jump to fflush (stdout), overwriting the _ IO_FILE structure into the attack code, and overwriting the (_ IO_sync_t, _ _ sync) in the virtual table structure of _ IO_jump_t into the address of the system function.

Effect picture of Exp attack:

0x04 official patch

The official patch determines whether the heap to be released is the last, and if not, it cannot be released, so that the UAF condition is not met and the vulnerability cannot be triggered.

The above content is how to analyze CVE-2017-16943-Exim-UAF vulnerabilities. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.