On Wed, Jul 30, 2014 at 8:10 AM, reox <[email protected]> wrote: > okay, that explains some bits. > i read on this site > https://securityledger.com/2014/07/old-apache-code-at-root-of-android-fakeid-mess/ > the following paragraph: > >> Application signatures are the basis of the Android application trust >> model, linking specific applications with a reputable certificate authority >> and implicitly trusting and, which tie back to specific certificate >> authorities and determining what permissions an application has on the >> device and what local resources it can access. Well, most application are either: (1) supplied by a developer and self signed; or (2) supplied by a vendor with signatureOrSystem. For examples of (1), Google Play is full of them. For an example of (2), look at the manifest of the bloatware packaged with phones by carriers and handset manufacturers.
The four platform keys essentially establish four CA's, but there's something that's lost in the translation. At best, I think its a private PKI. Its not a traditional, public PKI like PKIX with hundreds of trusted CAs and subordinate CAs. See, for example, http://www.kandroid.org/online-pdk/guide/release_keys.html. > while quouting Elenko's article: > >> Android solves this problem quite simply: it doesn't care about the actual >> signing certificate. Thus you do not need to have it issued by a CA >> (although you could, and most will happily take your money), and virtually >> all code signing certificates used in Android are self-signed. I think Nikolay pretty much nailed it for the common case. With that said, you could go to Verisign and get your end entity certificate signed. But it does not really provide any benefits. Your app's trust zone or security boundary is still created based on your end entity cert. It does not matter that Verisign endorsed or certified your public key. The Android OS does not have a built-in trusted store, so public CAs like Verisign mean nothing for the platform's private PKI. Your signed app *cannot* get 'system' in signatureOrSystem via an endorsement from Verisign. That's what the platform keys are for. > That means if and only if someone uses a certificate issued by a CA, this > app is vulnerable to this type of attack? That means if there is a > certificate that looks like it was signed from a CA I don't believe so. It does not pivot on a public CA. Android does not include a built-in trust store. Android utilizes a private PKI and uses the platform signing keys for that. What's not clear to me (but I don't believe it matters): does a platform key sign (or countersign) the adobe component? Or is the adobe component trusted via "hard coding" the trust into the source code. The implicit trust in the adobe component *coupled* with the incorrect verification is the crux of the problem. If you find another implicitly trusted component that includes an Issuer, then you have probably found another hole. But again, it does not need to be signed by a public CA. It just needs an issuer whose name you can fake. > this would make sense to me. Yes, you're close. But its not centered on public CAs. Its focused on the trust of a component, and exploitable because of a gap in the verification routines. Namely, the string comparison of the distinguished names (versus the verification of a signature). Jeff > Am Mittwoch, 30. Juli 2014 14:03:28 UTC+2 schrieb Jeffrey Walton: >> >> On Wed, Jul 30, 2014 at 4:58 AM, reox <[email protected]> wrote: >> > ... >> > >> > I do not understand what is the problem here? Does anyone have more >> > information? >> Taking from the 4th paragraph under "How It Works": >> >> <quote> >> The Android package installer makes no attempt to verify the >> authenticity of a certificate chain; in other words, an identity can >> claim to be issued by another identity, and the Android cryptographic >> code will not verify the claim >> </quote> >> >> *If* I am reading the 4th paragraph correctly, it appears (and using >> Adobe as an example): >> >> The app is using a certificate that is *not* self-signed. The app's >> certificate has an Issuer Distinguished Name of Adobe. However, the >> system does not verify Adobe actually issued the app's certificate The >> verification system is just performing a string comparison of the >> distinguished names. >> >> Actually, that is the case. From the 6th paragraph: >> >> <quote> >> ... instead defaulting to simple subjectDN to issuerDN string matching >> </quote> >> >> To summarize, signature verification on the chain is not being >> performed. Rather, a simpler [insecure] algorithm is used that >> consists of Distinguished Name matching. >> >> I attached an image that shows the relationship between Issuers and >> Subjects. It was ripped from Peter Gutmann's Engineering Security book >> (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). It should help >> you visualize what's going on. >> >> That's another good find by Forristal. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/d/optout.
