! This iOS 9.2.1 the latest update, Apple fixes a code execution vulnerability, and is by Zimperium zLabs two fellows Nikias Bassen and Joshua J. Drake in syslogd in the discovery. In this article, we will share how to determine the vulnerability and the vulnerability behind can allow an attacker with Root privileges in 6. 0 to 9. 2 version of iOS on the device to execute code The technical details. At first, we in the inspection process found that the fuzzy tester skip the syslog code, but when we investigated the test is crashing when it is on the syslogd in the open source section for a comprehensive review. Therefore, we only determined from the syslogd code bug and does successfully trigger a crash. Then we notify Apple and its security teams working together to solve the problem. Apple to react quickly. The complete security Bulletin is as follows: iOS / OS X syslogd stack buffer overflow Affected components: /usr/sbin/syslogd Affected platforms and versions: iOS 6.0 to 9.2 OS X 10.9 to 10.11.2 Suppliers Apple, Inc. CVE: CVE-2 0 1 6-1 7 2 2 The latest open source version: syslog-2 6 7 (OS X 10.10.5) Disclosure time The error is found and confirmed: 2 0 1 5 years 1 0 months 2 to 6 November Notice: 2 0 1 5 year 1 1 month 2 5 day Vulnerability fix: 2 0 1 6 1 1 4, with iOS 9.2.1 Summary Memory re-allocation process, the size of the computational error resulted in the establishment of a plurality of clients connected when the syslogd heap buffer overflow. Impact A local elevation of Privilege, remote code execution（WiFi under a trusted device or a DoS attack Description Syslogd process is through the iOS root permissions to run. We found a heap overflow vulnerability will lead to memory damage, and in some cases might lead to arbitrary code execution. Beyond the stack buffers boundary data will be the file descriptor of the value of the coverage. And there are some operation will also allow to write the value of the control. But want to take advantage of this loophole may not be simple. Background In the software running on the device may be a USB interface or by way of set the device in the same WiFi network on a remote connection to the syslog relay service com. apple. syslog_relay to access the device's system log, syslog in. But the premise is whether the use to which the media, the device must be configured to trust the machine before you can connect to the service. That is, you must first“pair.” Due to the passcode lock of the device can be unlocked only with a computer pairing, then in the untrusted devices on the use of this vulnerability would require a password. And the device is running on third-party applications have no way to directly with syslogd connection. Details This vulnerability root cause in source file syslogd. tproj / dbserver. c add_lockdown_session function. In performing this function, the programmer need to give an array of re-allocated memory size. The figure below is the code with problem: ! The 1 7 row 0 is the root of the problem is. Passed to the reallocf function of the size calculation wrong. This code should be for each new connection generates four bytes of time-domain file descriptor array, but the operator precedence rules of perspective calculation error. The code should read: ! The original code is the integer number of data bytes to increase the time domain number, and the above line of code is in the time domain the number after the first plus 1, then multiply by sizeof（int）。 So the meaning is different. Since the new version of iOS and OS X source code also can not be obtained. We need to pass the binary file disassembler to prove that appear in the latest version of this problem. And with the operator precedence rules of the application and the code in operation on the optimization of disassembly make the problem become more apparent. Below is the iOS 9.0.2 of the syslogd binary disassembly: the ! The same problem also in OS X syslogd binary file and the iOS 9.1 found,iOS 9.1 does not even need multiple connections to the com. apple. syslog_relay service to check the binary file you can confirm. As long as the heap within your important data is destroyed, syslogd crashes. The following figure is the OS X 10.11.1 of the syslogd binary disassembly: the ! Please pay attention to what the compiler in the two versions is in how the“1 *sizeof（int）”simplified to“sizeof（int）”, which makes the vulnerability even more obvious. When a new client connects, the function is first invoked, the execution time of this function to the initial buffer allocated first for the connected file descriptor. Because sizeof（int）the value always is set a value of 4, for the first time the global. lockdown_session_count value is 0, the calculated size is the correct 4 bytes. But when the second new client is connected, the the global. lockdown_session_count value becomes 1, the buffer size will be incorrectly calculated as 5 bytes. So, the third connection size is 6 bytes. If developers Put a new connection file descriptor is stored in the global. lockdown_session_fds array, with bytes of increasing occurs the actual stack overflow. The following figure is syslogd the syslogd. tproj / dbserver. c source file code excerpt: ! No. 1 7 9 lines of code, while it is also above the disassembly of the last row, showing the code in there is not enough memory to allocate the buffer overflow to write 4 bytes. Due to the memory allocation will usually be rounded to 8 bytes, so the establishment of two connections will not damage the memory. And create a third connection, the file descriptor will be written out of bounds may then lead to heap memory corruption. ! Of course, sometimes memory corruption occurs that may require more than three connections to make syslogd to crash. However, this depends on the stack after the block of data in the use after whether or how to be destroyed. In our test syslogd stay of execution is because remove_lockdown_session function the stack is corrupted.