test123test111 / ios-rce-vulnerability

Latest ios RCE Vulnerability disclosed by Google Security Researcher

ios-RCE-Vulnerability

Latest ios RCE Vulnerability disclosed by Google Security Researcher

the details has been taken from: https://thehackernews.com/2019/07/apple-ios-vulnerabilities.html

===================================================================================================== CVE-2019-8647 (RCE via iMessage) — This is a use-after-free vulnerability that resides in the Core Data framework of iOS that can cause arbitrary code execution due to insecure deserialization when NSArray initWithCoder method is used.

https://bugs.chromium.org/p/project-zero/issues/detail?id=1873


When deserializing a class with initWithCoder, subclasses of that class can also be deserialized so long as they do not override initWithCoder and implement all methods that require a concrete implementation.

_PFArray is such a subclass of NSArray. When a _PFArray is deserialized, it is deserialized with [NSArray initWithCoder:], which eventually calls [_PFArray initWithObjects:count:]. This method initializes the array with the objects provided by the NSKeyedUnarchiver, but does not retain references to these objects, so when the NSKeyedUnarchiver is released, the objects in the array will also be released, even though the user of the deserialized objects could still be using them.

This issue can be reached remotely via iMessage and crash Springboard with no user interaction.

To reproduce the issue with the files in pfarray.zip:

1. install frida (pip3 install frida)
2. open sendMessage.py, and replace the sample receiver with the phone number or email of the target device
3. in injectMessage.js replace the marker "PATH" with the path of the obj file
4. in the local directory, run:

python3 sendMessage.py

==================================================================================================

CVE-2019-8662 (RCE via iMessage) — This flaw is also similar to the above use-after-free vulnerability and resides in the QuickLook component of iOS, which can also be triggered remotely via iMessage.

https://bugs.chromium.org/p/project-zero/issues/detail?id=1874

The OfficeImport library appears to be loaded by the QuickLook.framework on demand (in _getOfficeImportLibrary()), and QuickLook is loaded into the Springboard process. As such, there might be scenarios in which OfficeImport is loaded in Springboard, making this bug remotely triggerable via iMessage without any user interaction. In any case, any process that has the OfficeImport library loaded and deserializes untrusted NSDictionaries is vulnerable even if secureCoding is enforced during unarchiving.

These type of bugs can be found somewhat automatically: the attached IDAPython script, when run in IDA Pro with the iOS dyld_shared_cache loaded, will enumerate all system libraries and determine classes that inherit from one of the whitelisted classes. It then writes a list of all candidates (classes that are allowed to be deserialized by NSKeyedUnarchiver with the whitelists present in iMessage parsing) to disk. Afterwards, these classes can be unarchived by first archiving a valid parent class (e.g. NSDictionary) and replacing the name of the parent class with the name of the child class in the serialized archive, then deserializing the archive again and invoking a few common methods on the resulting object, e.g. "count" or "objectForKey:". With that, the program will potentially crash when deserializing buggy child classes (as is the case for PFArray and OITSUIntDictionary). The attached archiveDict.m program can generate a valid NSDictionary archive, which can then be converted to xml format for easier editing with plutil -convert xml1 archive. unarchiveDict.m can afterwards deserialize the archive again into an NSDictionary instance. This approach, however, requires that all libraries loaded in the target process are also loaded in unarchiveDict, or else some of the classes won't be found and can thus not be deserialized.

===================================================================================================

CVE-2019-8660 (RCE via iMessage) — This is a memory corruption issue resides in Core Data framework and Siri component, which if exploited successfully, could allow remote attackers to cause unexpected application termination or arbitrary code execution.

https://bugs.chromium.org/p/project-zero/issues/detail?id=1884

There is a memory corruption vulnerability when decoding an object of class  NSKnownKeysDictionary1. This class decodes an object of type NSKnownKeysMappingStrategy1, which decodes a length member which is supposed to represent the length of the keys of the dictionary. However, this member is decoded before the keys are decoded, so if a key is an instance of NSKnownKeysDictionary1 which also uses this instance of NSKnownKeysMappingStrategy1, the mapping strategy will be used before the length is checked. The NSKnownKeysDictionary1 instance uses this length to allocate a buffer, and the length is multiplied by 8 during this allocation without an integer overflow check. The code will then attempt to copy the values array (another decoded parameter) into the buffer using the unmultiplied length.

It is not possible to control the copied values in this bug, because getObjects:range would then be called with a very large range and throw an exception. However, if the decoded values array is null, getObjects:range will do nothing, and then the code will go through a loop where it copies and retains entries from the values array into the buffer allocated based on the length member, going well past the end of both allocations.

This issue would likely be fairly difficult to exploit due to the uncontrolled nature of these copies.

To reproduce this issue in iMessage with knownkeydict:

1. install frida (pip3 install frida)
2. open sendMessage.py, and replace the sample receiver with the phone number or email of the target device
3. in injectMessage.js replace the marker "PATH" with the path of the obj file
4. in the local directory, run:

python3 sendMessage.py

=========================================================================================================

CVE-2019-8646 (File Read via iMessage) — This flaw, which also resides in the Siri and Core Data iOS components, could allow an attacker to read the content of files stored on iOS devices remotely without user interactions, as user mobile with no-sandbox.

https://bugs.chromium.org/p/project-zero/issues/detail?id=1858

The class _NSDataFileBackedFuture can be deserialized even if secure encoding is enabled. This class is a file-backed NSData object that loads a local file into memory when the [NSData bytes] selector is called. This presents two problems. First, it could potentially allow undesired access to local files if the code deserializing the buffer ever shares it (this is more likely to cause problems in components that use serialized objects to communicate locally than in iMessage). Second, it allows an NSData object to be created with a length that is different than the length of its byte array. This violates a very basic property that should always be true of NSData objects. This can allow out of bounds reads, and could also potentially lead to out-of-bounds writes, as it is now possible to create NSData objects with very large sizes that would not be possible if the buffer was backed.

To reproduce the issue with the files in filebacked.zip:

1. install frida (pip3 install frida)
2. open sendMessage.py, and replace the sample receiver with the phone number or email of the target device
3. in injectMessage.js replace the marker "PATH" with the path of the obj file
4. in the local directory, run:

python3 sendMessage.py

Please note that the attached repro case is a simple example to demonstrate the reach-ability of the class in Springboard. The actual consequences of the bug are likely more serious. This PoC only works on devices with iOS 12 or later.

===========================================================================================================

Note:Thanks to the Google zero day project.There is no contribution from my side.