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

Buffer overflow vulnerability CVE-2018-4407 example analysis, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Preface

Kevin Backhouse, a foreign god, released a blog post deconstructing the heap buffer overflow vulnerability (CVE-2018-4407) found in the kernel of Apple operating system.

This vulnerability allows attackers to send malicious packets to other unwitting users as long as they are connected to the same Wi-Fi network to trigger the crash and restart of any Mac or iOS device. Because this vulnerability exists in the core code of the system network, no anti-virus software can defend against it.

Devices running the following operating systems are vulnerable:

Apple iOS 11 and earlier: all devices (some devices upgraded to iOS 12)

Apple macOS High Sierra (up to 10.13.6 affected): all devices (fixed with security update 2018-001)

Apple macOS Sierra (up to 10.12.6 affected): all devices (fixed in Security Update 2018-005)

Apple OS X El Capitan and earlier: all devices

Fortunately, Kevin reported the vulnerability to Apple as soon as it was discovered, and Apple completely fixed it in its iOS 12.1 update package released on October 30th.

Overview

The vulnerability is caused by a heap buffer overflow of network code in the kernel of Apple's XNU operating system. Both iOS and macOS use XNU, so iPhone, iPad and MacBook are all affected. To trigger this vulnerability, the attacker only needs to connect to the same network as the target device and send malicious IP data to the IP address of the target device without luring the user into any interaction.

For example:

When a user uses a free Wi-Fi in a cafe, an attacker can join the same wireless network and send malicious packets to the user's device to crash and restart the device. (attackers can easily obtain the IP address of a device by using the NMAP tool. )

Because the cause of the vulnerability comes from the core code of the system, anti-virus software is also unable to defend. Kevin successfully tested this vulnerability on Mac running McAfee ®Endpoint Security for Mac. This has nothing to do with the software the user is running on the device, and malicious packets can trigger vulnerabilities even if no ports are opened.

It is further speculated that because attackers can control the size and content of the heap buffer overflow, they may exploit this vulnerability to execute remote code on the target device.

Mitigation measures

On devices that have not been upgraded to the latest version of the operating system, there are only two known mitigation measures:

Enabling hidden mode in the macOS firewall prevents attacks. This system setting is not enabled by default and requires the user to turn it on manually. Hidden mode is not supported on iOS devices.

Do not access the public wireless network. The only necessary condition to trigger this vulnerability is on the same Wi-Fi network, which does not support triggering by sending malicious packets over the Internet, and Kevin has been tested.

Loophole analysis

The vulnerability is due to a buffer overflow (bsd/netinet/ip_icmp.c:339) in the code:

M_copydata (n, 0, icmplen, (caddr_t) & icp- > icmp_ip)

The function icmp_error uses this code to "generate a packet containing an error message in response to the IP where the error occurred." It uses the ICMP protocol to send error messages, and the header that caused the error is contained in the ICMP message. The purpose of the call to m_copydata in line 339 above is to copy the header of the error packet to the ICMP message.

The problem is that the header may be too large for the target buffer. The destination buffer is mbuf,mbuf, a data type that stores incoming and outgoing network packets. In this code, n is an incoming packet (containing untrusted data) and m is an outgoing ICMP packet. As we can see, icp is a pointer to m. M deploy on line 294 or 296:

If (MHLEN > (sizeof (struct ip) + ICMP_MINLEN + icmplen)) m = m_gethdr (M_DONTWAIT, MT_HEADER); / * MAC-OK * / else m = m_getcl (M_DONTWAIT, MT_DATA, M_PKTHDR)

Looking down at line 314, mtod is used to get the data pointer to m:

Icp = mtod (m, struct icmp *)

Mtod is just a macro, so this line of code does not check whether mbuf is sufficient to hold the icmp structure. In addition, the data is not copied to icp, but to & icp- > icmp_ip, with a + 8-byte offset.

Without the necessary tools, Kevin cannot step into the XNU kernel in the debugger, so there is no exact value for the allocation size of the mbuf. Based on the information provided by the source code, it is speculated that a mbuf created by m_gethdr can hold 88 bytes, which m_getcl cannot determine. However, according to the experimental results, the condition of icmplen > = 84 can be satisfied when the buffer overflow vulnerability is triggered.

The vulnerability discovery process uses QL to find vulnerabilities.

Kevin is discovered when analyzing a buffer overflow vulnerability in the packet manager. The vulnerability is caused by a call to mbuf_copydata (including user-controlled size parameters), so a similar error can be found by writing a simple query script:

* * @ name mbuf copydata with tainted size * @ description Calling m_copydata with an untrusted size argument * could cause a buffer overflow * @ kind path-problem * @ problem.severity warning * @ id apple-xnu/cpp/mbuf-copydata-with-tainted-size * / import cppimport semmle.code.cpp.dataflow.TaintTrackingimport DataFlow::PathGraphclass Config extends TaintTracking::Configuration {Config () {this = "tcphdr_flow"} override predicate isSource (DataFlow::Node source) {source.asExpr (). (FunctionCall). GetTarget (). GetName () = "m_mtod"} override predicate isSink (DataFlow:: Node sink) {exists (FunctionCall call | call.getArgument (2) = sink.asExpr () and call.getTarget (). GetName (). Matches ("% copydata")}} from Config cfg DataFlow::PathNode source, DataFlow::PathNode sinkwhere cfg.hasFlowPath (source, sink) select sink, source, sink, "m_copydata with tainted size."

This is a very simple problem tracking method, and its lookup ranges from m_mtod to CopyData function parameter-sized data streams. The m_mtod function returns a data pointer to mbuf, which is likely to return untrusted data, so the mtod macro instruction is the root cause. M_mtod is just one of many sources of untrusted data in the XNU kernel.

Nine results are returned after querying using the above method, the first of which is vulnerability icmp_error, and the other eight results are more likely to be misreported.

Try QL on XNU

Unlike most other open source projects, XNU cannot get useful information by querying LGTM. Because LGTM uses the Linux process to build the project, XNU can only be built on Apple computers. Even on Apple computers, building XNU is not easy. Kevin referenced Jeremy Andrus's blog posts and was able to manually build snapshots of the three newly released XNU versions (download snapshot 10.13.4, 10.13.5 XNU 10.13.6). Since Apple has not released the source code for 10.14 (12 of Mojave/ iOS), it is unable to create a QL snapshot to run targeted checks. To run query scripts on these QL snapshots, download QL for Eclipse and click here for instructions on how to use QL for Eclipse.

This is the answer to the example analysis of buffer overflow vulnerability CVE-2018-4407. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.