{"id":26386,"date":"2019-08-23T17:34:08","date_gmt":"2019-08-23T21:34:08","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=26386"},"modified":"2021-07-06T17:17:37","modified_gmt":"2021-07-06T21:17:37","slug":"imessage-nskeyedarchiver-and-_nsdatafilebackedfuture","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/08\/23\/imessage-nskeyedarchiver-and-_nsdatafilebackedfuture\/","title":{"rendered":"iMessage, NSKeyedArchiver, and _NSDataFileBackedFuture"},"content":{"rendered":"<p><a href=\"https:\/\/googleprojectzero.blogspot.com\/2019\/08\/the-many-possibilities-of-cve-2019-8646.html\">Natalie Silvanovich<\/a>:<\/p>\n<blockquote cite=\"https:\/\/googleprojectzero.blogspot.com\/2019\/08\/the-many-possibilities-of-cve-2019-8646.html\"><p><a href=\"https:\/\/bugs.chromium.org\/p\/project-zero\/issues\/detail?id=1858\">CVE-2019-8646<\/a> 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 <code>NSKeyedArchiver<\/code> deserialization can make a bug more versatile. It&rsquo;s also a good example of how minor functional bugs can make a vulnerability more useful.<\/p><p>Please note that this blog post assumes some familiarity with <code>NSKeyedArchiver<\/code> deserialization. If you haven&rsquo;t read our general <a href=\"https:\/\/googleprojectzero.blogspot.com\/2019\/08\/the-fully-remote-attack-surface-of.html\">post<\/a> on iMessage, I&rsquo;d recommend reading that first.<\/p>\n<p>[&#8230;]<\/p>\n<p>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 <code>NSData<\/code> class makes, that the <code>length<\/code> property will always return the length of the <code>bytes<\/code> property. This is because the length of the buffer returned by <code>[_NSDataFileBackedFuture bytes]<\/code> is the length of the loaded file, and has no relationship to the deserialized length returned by <code>[_NSDataFileBackedFuture length]<\/code>.<\/p>\n<p>[&#8230;]<\/p>\n<p>Putting this all together allowed for a file to be read remotely from an iPhone.<\/p><\/blockquote>\n\n<p id=\"imessage-nskeyedarchiver-and-_nsdatafilebackedfuture-update-2019-09-13\">Update (2019-09-13): <a href=\"https:\/\/twitter.com\/5aelo\/status\/1172534071332917248\">Samuel Gro&szlig;<\/a>:<\/p>\n<blockquote cite=\"https:\/\/twitter.com\/5aelo\/status\/1172534071332917248\">\n<p>After looking at iOS 12.4.1 I&rsquo;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 \n@natashenka and I found from being remotely exploited :)<\/p>\n<\/blockquote>","protected":false},"excerpt":{"rendered":"<p>Natalie Silvanovich: 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 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"2019-08-23T21:34:11Z","apple_news_api_id":"d86739c2-bb07-4bce-ba54-fc101e889937","apple_news_api_modified_at":"2021-07-06T21:17:41Z","apple_news_api_revision":"AAAAAAAAAAAAAAAAAAAAAg==","apple_news_api_share_url":"https:\/\/apple.news\/A2Gc5wrsHS866VPwQHoiZNw","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[131,69,2095,140,31,1610,355,71,48],"class_list":["post-26386","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-bug","tag-cocoa","tag-exploit","tag-imessage","tag-ios","tag-ios-12","tag-privacy","tag-programming","tag-security"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/26386","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=26386"}],"version-history":[{"count":2,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/26386\/revisions"}],"predecessor-version":[{"id":26583,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/26386\/revisions\/26583"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=26386"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=26386"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=26386"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}