Apple syslogd Elevation of Privilege Vulnerability, affecting many iOS, OSX versions (CVE-2016-1722)

Apple syslogd Elevation of Privilege Vulnerability, affecting many iOS, OSX versions (CVE-2016-1722)

 

 

In the latest iOS 9.2.1 update, Apple fixed a code execution vulnerability found in syslogd by two Zimperium zLabs researchers Nikias Bassen and Joshua J. Drake.

In this article, we will share the technical details on how to determine the vulnerability and how attackers can execute code on iOS devices from version 6.0 to version 9.2 with Root permissions.

At first, we found that the fuzzy tester skipped the syslog code during the check process, but when we investigated the test crash issue, it conducted a comprehensive review of the open source part of syslogd. Therefore, we identified the bug of syslogd code and successfully triggered the crash. Then we will notify apple and cooperate with its security team to solve the problem. Apple quickly responded. The complete security announcement is as follows:

Syslogd heap buffer overflow of iOS/OS X

Affected components:

/usr/sbin/syslogd

Affected platforms and versions:

IOS 6.0 to 9.2OS X 10.9 to 10.11.2

Supplier

Apple, Inc.

CVE:

CVE-2016-1722

The latest open source code version:

syslog-267 (OS X 10.10.5)

Disclosure time

Error detected and confirmed: July 22, October 26, 2015 notification: July 22, November 25, 2015 vulnerability fix: July 22, January 14, 2016 and iOS 9.2.1

Summary

The heap buffer of syslogd overflows when multiple clients are established due to a large or small computing error during memory reallocation.

Impact

Local Privilege Escalation, Remote Code Execution (devices trusted under WiFi) or DoS Attacks

Introduction

The Syslogd process runs through the root permission of iOS. We found that a heap overflow vulnerability could cause memory corruption and may cause arbitrary code execution in some cases. Data that exceeds the boundary of the heap buffer will be overwritten by the file descriptor value. Some operations also allow control of the write value. However, it is not easy to exploit this vulnerability.

Background

Software running on the device can be remotely connected to the syslog Relay Service (com. apple. syslog_relay) to access the system log (syslog) of the device ). However, the premise is that no matter which media is used, the device must be configured as a trusted machine to connect to the service. That is to say, you must first "pair ".

Because a device with a password can only be paired with a computer when it is unlocked, a password is required to exploit this vulnerability on untrusted devices. Moreover, third-party applications running on the device cannot directly connect to syslogd.

Details

The root cause of this vulnerability lies in the add_lockdown_session function in the source file syslogd. tproj/dbserver. c. When executing this function, the programmer needs to re-allocate the memory size to the array. Is part of the Code:

 

Row 3 is the root cause of the problem. The size passed to the reallocf function is incorrect. This code should generate an array of four bytes of time domain file descriptors for each new connection, but the calculation error is returned from the perspective of operator priority rules. The Code should be changed:

 

In the original code, the number of bytes of integer data is increased to the number of time domains. The above code line adds 1 after the number of time domains, and then times sizeof (int ). The meaning is different.

The source code of the new iOS and OS X versions cannot be obtained. We need to use the disassembly of the binary file to prove this problem in the latest version. In addition, with the application of operator priority rules and code optimization in operations, disassembly makes the problem more obvious. Is the syslogd binary disassembly of iOS 9.0.2:

 

The same problem was found in the syslogd binary file of OS X and iOS 9.1. iOS 9.1 does not even need to connect to com multiple times. apple. the syslog_relay service checks the binary file to confirm. Syslogd crashes as long as important data in the heap is damaged. Is the syslogd binary disassembly of OS X 10.11.1:

 

Note how the compiler simplifies "1 * sizeof (int)" to "sizeof (int)" in these two versions, which makes the vulnerability more obvious.

When a new client is connected, the function is called for the first time. When executed, the function allocates the first file descriptor for the connection to the initial buffer. Because the sizeof (int) value is always set to 4, the first time the value of global. lockdown_session_count is 0, the calculated size is correct 4 bytes. However, when the second new client is connected, the value of global. lockdown_session_count becomes 1, and the buffer size is incorrectly calculated as 5 bytes. Similarly, the size of the third connection is 6 bytes.

If the developer stores the new connected file descriptor in the global. lockdown_session_fds array, the actual heap overflow will occur as the number of bytes increases. Is an excerpt from the source code of syslogd. tproj/dbserver. c In syslogd:

 

The Code in line 2 is also the last line of the disassembly above, indicating that the Code overflows into four bytes in the buffer with insufficient memory allocation. Since memory allocation is usually rounded to 8 bytes, establishing two connections will not damage the memory. After the third connection is created, the file descriptor is written out of the bounds and may cause heap memory corruption.

 

Of course, sometimes Memory Corruption may require more than three connections to crash syslogd. However, this depends on whether or how the data after the heap block is exploited is damaged. In our test, syslogd abort execution because of heap corruption in the remove_lockdown_session function.