There has been a lot of chatter on social media and in forums about the Android master key vulnerability controversy caused by its public disclosure by Jeff Forristal, CTO of Blue Box. Some very sharp developers and security analysts posted coding explanations and personal opinions.
According to folklore, when Andy Rubin visited Google, the then independent Android was not looking for investment or acquisition, but for Google's support in promoting the Android Open Source Project (AOSP) to prevent a smartphone operating system monopoly by Symbian, RIM, Microsoft or Apple. Google’s CEO Larry Page bought Android because he understood an open source phone OS would foster innovation and prevent a monopoly.
The price paid for open source innovation and the elimination of a monopoly smartphone OS threat is an open-minded and outspoken open source developer community, which is at the root of this controversy.
Forristal is enjoying the notoriety that will pack his talk at the INFOSec industry’s Black Hat Conference in August, but his motivation extends beyond self promotion and appears to be sincere. Unless Forristal’s Linkedin profile has been contrived, he is clearly qualified to speak on the topic. Reading the commentary to Al Sutton’s explanation of how the exploit works posted on Google Plus is very insightful.
The issue is one of responsible disclosure, which is an open source developer principal to report a vulnerability first to the project maintainer, in this case Google, allowing them the time to create and distribute a patch. But when the vulnerability is significant and the patch is not readily available, many members of the open source developer community believe it is a social responsibility to disclose the threat publically. Based on Sutton’s post, responsible disclosure was Forristal’s primary motivation because it has been 90 days since the patch was released, but the patch has not been widely distributed.
According to Google spokeswoman Gina Scigliano:
"Bluebox approached Google with details of the exploit in February and by early March Google had released a patch to its OEMs and partners. Some of the partners such as Samsung are already shipping patched smartphones and tablets."
Apparently for Forristal, Google has not reached deep and far enough into the Android developer and consumer community to ensure the that the threat is mitigated, because he added to Sutton’s Google Plus post:
"Whether you agree with it or not, consider how this issue is playing out. The media (hype or otherwise) got people's attention, worldwide. It informed them there is something there. AOSP consumers can start actively engaging, looking for the patch (checking AOSP commits), asking the right questions on how to update & protect their users."
According to Accuvant senior research consultant Zach Lanier:
"This is mainly a threat to updates to existing apps. The way that the PackageParser and ZipFile classes work is flawed. As long as there is only one entry for a given file in the application package, everything works correctly and the authentic update is installed. But when a modified app has been downloaded where there are two duplicate file entries, one referencing the location of an authentic file and one referencing the illegitimate file, the first one is validated but the second entry will be the one that is installed. With this technique, it would be possible to take over the smartphone by modifying an existing privileged application."
But Google’s Scigliano also claimed:
"We have not seen any evidence of exploitation in Google Play or other app stores via our security scanning tools. Google Play scans for this issue - and Verify Apps provides protection for Android users who download apps to their devices outside of Google Play."
Versions of Android dating back to Gingerbread include Verify Apps using the same scanning technology as the Google Play Store to scan the apps downloaded from alternative app stores. App verification covers about 95% of the Android smartphones.
So how big a threat is this exploit? For this exploit to work, some nefarious hacker would need to hijack a legitimate app and modify it, as described by Al Sutton and Pau Oliva in his Proof of Concept, and deliver it as an update through an alternative Android app store that does not scan for this exploit. Then a user would need to download the exploited app to a smartphone with app verification turned off, or to a pre-Gingerbread smartphone. It seems like a pretty small threat.
In the way Lanier describes the exploit, the getinputstream method bug introduced an attack vector that could be a major threat without app verification or scanning for vulnerabilities.
This threat may only be academic. But the controversy and subsequent technical and AOSP resolution of this controversy support a strong and innovative AOSP community. Controversies arising from responsible disclosure are analogous to the controversies sparked by freedom of speech, in that they can be disruptive, but nevertheless support a strong democracy.