iMessage, NSKeyedArchiver, and _NSDataFileBackedFuture
CVE-2019-8646 is a somewhat unusual vulnerability I reported in iMessage. It has a number of consequences, including information leakage and the ability to remotely read files on a device. This blog post discusses the ways that an attacker could use this bug. It is a good example of how the large number of classes available for
NSKeyedArchiverdeserialization can make a bug more versatile. It’s also a good example of how minor functional bugs can make a vulnerability more useful.Please note that this blog post assumes some familiarity with
NSKeyedArchiverdeserialization. If you haven’t read our general post on iMessage, I’d recommend reading that first.[…]
There are two immediate problems with being able to deserialize this class in an untrusted context. One is that it has the potential to allow a process to access a file that it is not authorized to access, because the process doing the deserialization is the one that loads the file. When I reported this bug, I thought that this was more likely to be a concern for deserialization that occurs locally via IPC as opposed to deserialization that occurs on a remote target like iMessage. The second is that this class violates one of the guarantees that the
NSDataclass makes, that thelengthproperty will always return the length of thebytesproperty. This is because the length of the buffer returned by[_NSDataFileBackedFuture bytes]is the length of the loaded file, and has no relationship to the deserialized length returned by[_NSDataFileBackedFuture length].[…]
Putting this all together allowed for a file to be read remotely from an iPhone.
Update (2019-09-13): Samuel Groß:
After looking at iOS 12.4.1 I’m happy to say that Apple has hardened iMessage by no longer allowing child classes during its NSUnarchiving. This prevents almost all of the vulnerabilities @natashenka and I found from being remotely exploited :)
