In-depth exploration found in the wild iOS exploit chain VI-vulnerability warning-the black bar safety net

In this article, we will Analysis on your iOS device to get the normal permissions of the shell of the WebKit exploit method, where all the vulnerabilities are available on iOS’s sandboxed renderer process WebContent implemented shellcode code execution. Although on iOS Chrome will also be affected by these browser vulnerabilities to attack, but the attacker would just use them to locate the Safari and the iPhone’s location.
This article will first briefly describe each use of the WebKit vulnerabilities and an attacker how from build a memory read/write primitives, and then outlines for shellcode code execution techniques as well as how to bypass the existing JIT code injection mitigation measures.
Interestingly, these vulnerabilities do not have a vulnerability to bypass on the A12 on the device are enabled based on PAC JIT strengthen mitigation measures. Exploits by vulnerability to support the latest iOS version, if the exploit is missing in the version check, it will be based on the repair date and prior to the vulnerability to guess the supported version range.
The sandboxed renderer process using the first get memory read/write functions, and then the shellcode injected into the JIT area to obtain the native code execution privileges. It seems every time you broke a new major can exploit the vulnerability, the new vulnerability will be added to the framework to use to do read/write check, and then inserted into the existing exploit frameworks. The exploits used are also common exploit techniques, for example, first create addrof and fakeobj primitive, then fake JS object to implement the read/write.
For many exploit programs, it is unclear whether they have in some 0day or 1day on successful use. Now also don’t know the attacker is how to first get these vulnerability information. Typically, they are used to repair the finish after the release of the public exploit to use. WebKit in the fix version is sent to the user before publishing the vulnerability details. CVE-2019-8518 is in 2019 2 May 9, WebKit HEAD disclosed in repair, submitted for 4a23c92e6883 it. This commit contains a test case, the test cases triggered a vulnerability and lead to a JSArray of cross-border access, this situation is usually very easy to exploit. However, the fixes only in 2019 3 December 25 release iOS 12.2 user post, is in about the vulnerability details publicly after a month and a half before release. The technical ability of the user to be within a few days time to replace the underlying vulnerabilities, thereby obtaining the advantage of the latest capabilities of the device, without self-tap new holes. This may occur at least in some of the following vulnerabilities in.
In order to do the comparison, the following is a list of the other browser vendors is how to deal with this vulnerability window problems:
Google and Chromium the same problem exists, for example, submitted 52a9e67a477b fix for CVE-2018-17463-in. However, it seems some of the recent vulnerabilities release no longer contains the JavaScript test cases. For example, our team members Sergey Glazunov reported the following two for the vulnerability fix: aa00ee22f8f7 for vulnerability 1784 and 4edcc8605461 for vulnerability 1793 in.
Microsoft will open source the Chakra engine in the security fixes that confidential treatment until the fix has been sent to the user before the public. Then released the repair after the procedure and publishes the CVE number. For this example, see commit 7f0d390ad77d it. However, it should be noted that the Chakra will soon be the Edge of the V8（Chromium’s JavaScript engine replaced.
Mozilla directly prohibits a public repository of security fixes, they will directly release the next version. In addition, it is not disclosed for triggering a vulnerability in the JavaScript test cases.
However, it is worth noting that, even if the Don’t get the JavaScript test case, you can still through a code patch written in the PoC and eventually exploit the vulnerability.

0x01 exploit 1: iOS 10.0~10.3.2
This exploits the target is CVE-2017-2505, initially by lokihardt report for Project Zero issue 1137, and in 2017 to 3 January 11, on the WebKit HEAD by submission 4a23c92e6883 repair. The fix is then in the 5 on 15, publishing to the iOS 10.3.2 the user. Interestingly, the exploit exp is almost the WebKit repository in the bug report and test file exactly the same. You can see in the image below, the left image is displayed in the WebKit code repository publish a test with the example on the right shows the triggering of vulnerabilities in the wild exploit code part.
! [](/Article/UploadPic/2019-9/2019917134229760. png)
The vulnerability will lead to the use of controlled data writes to achieve the JSC heap bounds. Attacker destruction of controlled JSObject one of the first QWord, changing its structure ID to the run-time type information with JSCell associated with to make it appear as a Uint32Array with. Thus, they actually created a fake TypedArray, will directly allow them to construct a memory read/write primitives.

0x02 exploit 2: iOS 10.3~10.3.3
The exploit is for CVE-2017-7064 or its variant, which was originally by lokihardt found and reported as issue 1236 in. The vulnerability has been in 2017 4 November 18 in the WebKit HEAD by submission ad6d74945b13 repair, and in 2017, the 7 on 19, released to the iOS 10.3.3 of the user. The vulnerabilities could cause uninitialized memory to be treated as JS array of content, through reactor operation technology, you can control the uninitialized data, this time by the double-precision and JSValues between the type of confused structure addrof and fakeobj primitive, so that by construction forged TypedArray get memory read/write.

0x03 exploit 3: iOS 11.0~11.3
This exploit is a WebKit vulnerability 181867, the CVE number might be CVE-2018-4122。 It in 2018 1 November 19 in the WebKit HEAD in repair, and in 2018 3 May 29, released to iOS 11.3 the user. The vulnerability is typical of the JIT side-effect problems. It is unclear how the attacker is in early 2018 will know of this vulnerability. The vulnerability through the confusion is not initialized double, and Whether the array built addrof and fakeobj primitive, and then again by forgery to obtain memory read/write a typed array of objects.

0x04 exploits 4: iOS 11.3~11.4.1
This exploit is for the 2018 年 5 月 16 filed in the b4e567d371fd fix the vulnerability, and corresponding to the WebKit bug report 185694 it. Unfortunately, we are unable to determine the allocation to this issue of the CVE, but it seems that the patches in 2018 7 May 9, publishing to the iOS 11.4.1 the user. This is another JIT side-effect issues, similar to the previous vulnerability, again constructed fakeobj primitive to forge a JS object. However, it has now been released Gigacage mitigation measures. Therefore, construction of the pseudo-ArrayBuffers / TypedArrays are no longer useful.
The exploit constructs a fake unboxed double Array, and get an initial, limited memory read/write primitives. Then using the initial primitive to disable Gigacage mitigation measures, and then continue to use TypedArrays to perform behind the exploits.

0x05 exploit 5: iOS 11.4.1
The exploit is for CVE-2018-4438 vulnerability, the lokihardt report of 1649 it. This vulnerability is in 2018 10 May 26 using the commit 8deb8bd96f4a repair, and in 2018, 12 月 5 issued to the iOS 12.1.1 the user. The wrong hole you can build a proxy the prototype of the array, and then, by the JIT-compiled code in the trigger change, this vulnerability is converted to the JIT side-effect problems. The vulnerability before the vulnerability is very similar, first using the limited JS array read/write disable Gigacage mitigation measures, and then by TypedArrays perform a full read/write the shellcode to be injected.

[1] [2] next