Have you checked if APKs that take advantage of this bug are flagged by the Google Play Services verifier?
I can't imagine a legitimate reason to use these zip file corner cases, so it seems like the perfect sort of issue to detect and flag. And it would be a good spot-check of Google's verifier since they've had a few months to add the check.
That is an excellent question. I just now turned on that feature (I normally keep it off, in case Google is watching it and learns something about an exploit I might be working on) and verified that it correctly warns about both bug #8219321 and bug #9695860. It does not, however, do anything to protect me against bug #9950697. I am now even more impressed with the extent to which they simply do not seem to care about proactively protecting users from these kinds of security issues :(.
When checking #8219321 and #9695860 did you make new APKs that were never "in the wild" or did you rely on existing examples?
While they haven't gone into details, I've gotten the impression that their checks are primarily based on recognizing bad APKs rather than recognizing bad constructs. While that's certainly a good defense to include (for attacks that are expensive to recognize and as a general backup), it is limited because it's inherently backward-looking. I guess I'm wondering how deep their "not proactive" approach goes.
I used Impactor to perform this test. Impactor generates all of the packages it needs at runtime (it includes enough of the aapt machinery to compile its own manifest files). In order to work around some situations where packages get "wedged" on some devices, all of the packages it generates have a unique package identifier based on the current timestamp. The APK files I was installing are thereby always "never before seen" files.
(FWIW, it is my understanding that Verify Apps is part of Play Services, so updates to it can be pushed at any time to all devices: if they previously were just sending a SHA-1 of the entire APK to the server, and now needed to check if the file size divided by the current day was a mersenne prime, they could push an update to do that on the client. They thereby are not limited to only "inherently backward-looking" techniques for this protection.)
Thanks for the extra detail. It's good to see that Google is clearly doing more than just signature-style checks. I knew they could do that sort of thing in Play Services, but, based on past coverage/discussion I wasn't confident that they were.
That still leaves open the question of security issues that aren't well-known, of course. Thinking about it a bit more, I can see the attraction of not adding extra complexity to the Play Services verifier until they "had to". If they're doing server-side checks and analysis that include undisclosed/low-profile issues that could be a reasonable balance (even if there is some lag time involved for simulations and the like), but if they're not...
Sadly, we're unlikely to ever know the difference.
It sometimes happens in various scenes (I specifically recall PS3) where people post hashes of proof of some various hack/achievement/etc that is private for whatever reason. They want to be able to claim "first" if someone else finds the same hack later. Hashes of keys were posted for the PS3.
Wasn't the old version of this trick sending the information in a well sealed envelope through the mail to get a dated postmark? More than 140 characters but you can only prove it once by unsealing the envelope!
I never understood this trick. Surely you could just mail an empty envelope ahead of time for the postmark, then put whatever you wanted to prove in it later?
I think the idea is that you keep it sealed until it is needed, then open it in some way that creates a legally admissible proof of the contents (maybe opened by a notary or something; and examined for postmark/envelope tampering by some sort of expert in that field, who can testify his training leads him to believe it is authentic.)
Hey saurik, I just wanted to say that I've really enjoyed reading all of your "Master Key" analyses. It's fascinating to see an exploit broken down in such detail, and you have a knack for explaining things clearly and succinctly. Thanks for the good reads.
I can't imagine a legitimate reason to use these zip file corner cases, so it seems like the perfect sort of issue to detect and flag. And it would be a good spot-check of Google's verifier since they've had a few months to add the check.