Security firm Bluebox Security has uncovered a vulnerability in Google’s Android mobile operating system , which could allow attackers to trick an Android device into installing malicious applications. The package installer component of Android doesn’t check the validity of the certificate chain.
We don’t know all of the details yet. Bluebox is waiting on formally presenting the vulnerability at the Blackhat security conference, but it looks bad. Affected versions appear to be all Android releases after version 2.1 and before 4.4.
According to this article, it appears the problem has been traced to the inclusion of code from the now discontinued Apache Harmony project. The worst part of this vulnerability is due to the way Android is deployed in the marketplace. Many Android users will never see a fix, because their handset manufacturer no longer supports their handset. They will remain in the wild, and vulnerable, until they’re taken out of service.
When cryptographic gaffes happen it’s very tempting to point to a new protocol like DNSSEC, and claim it does not have this problem. Indeed, I wrote about the new trust models presented by DNSSEC, DANE, and Certificate Transparency earlier this month. I argued that we need to move away from trusting centralized entities such as Certificate Authorities, and instead distribute our trust model using both Certificate Transparency(RFC 6962), and DNSSEC / DANE.
However, the real culprit here isn’t the hard coding of CA’s in applications, or the Public Key Infrastructure(PKI) that affords the signing of certificates by multiple authorities. The real culprit here is Android’s abject lack of checking the certificate chain. From what we know of the vulnerability, Android’s package installer just implicitly trusts the presented certificate chain, without any verification.
No new technology or protocol can rectify this kind of broken behavior. If Android’s package installer implemented certificate verification via DNSSEC / DANE, it would still need to query DNS for the hash of the certificate and verify it. If Android’s package installer checked a package’s certificate against a public log, a la Certificate Transparency, it would actually have to check it. The lesson here is not that one technology is better than the other, but that actual follow through is important. If your security model is based on certificate chains, then verify the certificate chain.
There are still obvious advantages to an Internet with fully deployed DNSSEC, and an Internet where CAs append their issued certificates to a public log for Certificate Transparency. We just should not forget that implementations matter, it’s usually the implementations where the flaws are found, and not the underlying protocols themselves.
If you would like to learn more about Certificate Transparency, please visit certificate-transparency.org. If you would like to learn more about DANE, please visit our resource page on DANE. If you would like to get started with deploying DNSSEC please visit our DNSSEC resources, or begin with our “Start Here” page to help find resources most appropriate for your type of organization. If you have a Certificate Transparency, DANE, or DNSSEC case study you think we should consider for inclusion on our site, please contact us – we are always looking for more!