Opengapps: Please improve your security practices

[jsbax]

You are releasing critical system software in a way that makes it extremely hard to verify that it is not malware. Please fix this so that users aren't needlessly put in danger.

Easy issues:

1. You are serving opengapps.org via HTTP, which means anyone in the network path can replace anything with malware. You should use HTTPS only instead along with HSTS. You can get HTTPS support by obtaining a cheap domain vaildated certificate or hosting the website on GitHub Pages or putting it behind CloudFlare for free.
2. You are distributing MD5 checksums, but MD5 is broken. You should use SHA-512 or SHA-256, in addition to MD5 if the Android recoveries only support checking MD5.
3. You are not signing the checksum files or the data files with PGP/GPG. You should do so, using a 4096-bit or larger RSA key.

Another big issue is that you are shipping binaries that come from Google, but there is no way to tell that they are actually the untouched binaries as opposed to malware added by you or someone who compromised your development machine.

You should really change the whole build process so that it consists of a script that downloads Google Nexus factory images or any other source either from a Google HTTPS website or digitally signed by Google, checks any Google signature that is present and extracts the binaries on the user machine.

This way someone who is technically capable of building gapps himself can be sure that they are getting the latest original files from Google without having to trust you.

[mfonville]

First of all, it is not 'critical' system software, but yes, it is system software and should be treated carefully. Actually we did recentlly write a blogpost about this https://plus.google.com/+OpengappsOrg/posts/LvpqiQxEhyg and do think that security is important.

1. We are serving actually on opengapps.ORG and HTTPS would be nice, but GitHub does not support this currently on custom domains. For now serving the website itself (which is just a simple frontend) is not the highest priority for focusing our security efforts and we will probably just wait for GitHub to sort it out (they are busy with it, afaik). If you do want to access the releases via HTTPS, please use GitHub directly via e.g. https://github.com/opengapps/arm/releases .
2. The checksums are not for security, but for validating if the download was correctly. We adhere to the processes that are supported by the android recoveries, because those only do (automated) checks for the md5 to verify the file. But it is important to note that actual full zip integrity and verification is not done by this md5, but by the MANIFEST within the ZIP using the jarsigner signature, and another RSA signature for the whole ZIP content in the tail of the ZIP file itself. (Look into the jarsigner documentation for details).
3. See previous point, the checksums would then not be processable by the recovery. Signature and verification are done using the default Android platform test keys.

Your other point, validating whether the binaries really come from Google, is a valid point. We are working on it, so if'd browsed our issue list or did check the G+ article, you can see that the tracking bug for this is: https://github.com/opengapps/opengapps/issues/92
And for automatic extraction of Nexus images @Lekensteyn is doing good work and is tracked in https://github.com/opengapps/opengapps/issues/70

I will close this bug now, not because I don't find your points important, but because I think those current issues are a better place to keep progress.
If you do find this interesting, please contribute to the discussions there. Actually I am still figuring out e.g. if we can do some kind of CA checking on the Google APKs, and how to deal with de-odexed APKs that lack a signature for classes.dex

Also we still need some help on issue https://github.com/opengapps/opengapps/issues/44 to improve our shell version of jarsigner to make correct signatures in the ZIP tails.

[jsbax]

Thanks to answering, it's great to see that it's actually being taken seriously.

The real issue is then that while you are indeed doing great work, it's hard for the people who are new to gapps or Android to find out you are doing so, because the opengapps.org site (which is what the CyanogenMod wiki points to) doesn't seem to mention any of it: it would be nice to at least for instance add a link to the blog post, or this github issue.

Answers to the three points:

1. I would suggest adding a temporary redirect from opengapps.org to the HTTPS GitHub pages domain until it's fixed.
2. OK, you should then keep the md5 checksums, but also add SHA-256 or SHA-512 for manually checking the download with sha256sum/sha512sum (or equivalent Windows tools).
3. You can put the signature in a separate ".asc" file checkable by GnuPG, which would not interfere with the recovery. That should be done with your own private key, so once people decide to trust you, they can be sure that all gapps packages are from you even if there was a vulnerability in GitHub that allowed someone to replace the files, or something like that.

I'm not sure what "Android platform test keys" are, but if anyone can sign using them, they cannot provide any security, and signing with them should just considered an integrity checking measure or a necessary step to make the package installable.

[mfonville]

1. I think that would be overdone, especially considering that neither of any of the other XDA-based GApps, let alone the ROMs that people use, are hosted on HTTPS. So I rather provide HTTP-based frontend than none, and rather a recognizable domainname (that people 'know' and browse directly to).
2. imho MD5 is sufficient to check if the download did succeed or not. Even though md5 is not a secure hashing mechanism, it is a reliable mechanism to detect faulty downloads.
3. If people really care about security, they shouldn't trust any signature of me, since they don't know me neither whether I (or my buildbot machine) are trustworthy. Adding my private signature does not really provide any extra security. Also, signing the zip file with the test keys is the only key with have available at the moment that can be correctly verified by the recovery mechanisms.

The security situation for flashing anything from Android recovery is NOT great at the moment. If somebody really cares about security the only real step they can take at the moment is to NOT download pre-compiled ZIPs from the internet, but to generate them themselves from a trusted set of APKs. That is also why imho this project is so important compared to the 'manual' GApps packagers, because you'll be finally getting the tools to do this.

[bgiesing]

@mfonville Since you and me both have a Keybase account, maybe we should add a opengapps.org proof via text file (similar to this) to the site with all the members we can. This way people can verify?

[mfc]

1. I think that would be overdone, especially considering that neither of any of the other XDA-based GApps, let alone the ROMs that people use, are hosted on HTTPS. So I rather provide HTTP-based frontend than none, and rather a recognizable domainname (that people 'know' and browse directly to).

CyanogenMod serves downloads over HTTPS: https://download.cyanogenmod.org/

You can just have the links to download go to the Github-hosted downloads.

The checksums are not for security, but for validating if the download was correctly.

"validating download" = "securely download". Please take @jsbax's suggestions seriously, including GPG signing.

CM also provides SHA1 hashes (they used to provide MD5). CM is not known for security, they have just adopted minimal best practices because they want to be taken seriously. I think having opengapps be at the same minimal level would be appropriate as opengapps becomes the default recommended gapps package for CM: https://wiki.cyanogenmod.org/w/Google_Apps

[mfonville]

I see that GitHub now also enabled HTTPS for the download urls of the releases' assets, so yes, I will enable HTTPS for the download links. When checking to fix this, it appears we were already using HTTPS links, so this complaint is not valid.
Be noticed that opengapps.org itself is still only served over HTTP though, since we are dependent on GitHub HTTPS support for hosted sites using CNAMEs, which they don't yet do.

I am busy with the GPG signing, soon the OpenGApps.org prebuilts will have their own signature. I do have to set-up some extra security practices on the buildbot first. (I want to isolate and sandbox the building processes, to reinforce the security of it). The signature still does only provide limited guarantee, since the best and only safe way to get trusted GApps is to build them yourself (see my earlier comment about that).

If you could figure out if recoveries are willing/able to support SHA1 hashes to verify the integrity of downloads, then we could also add those. Because at the the moment they do not, which would defeat the purpose of that hash. Also please re-read my comment that the hash does not give any verification about the integrity of the file, only whether the file was correctly downloaded, for which MD5 suffices. The integrity of the file is still checked using the certification within the META-INF directory and the certificate in the tail of the zip file.

[mfonville]

FYI from 13 dec and later on the prebuilt OpenGApps packages from opengapps.org will be signed with a custom certificate.

[jumper444]

1) as of August 2017, I don't see any certificate signing of OpenGapps packages. Am I missing something?

2) from above: "..I would suggest adding a temporary redirect from opengapps.org to the HTTPS GitHub pages domain until it's fixed..." Since the opengapps.org website isn't https a malicious party can just rewrite the page during delivery (router/firewall/proxy..the technology exists and is documented to be in use by wikileaks and others in the last few years) to create malicious/compromised download links on the page. The root of the problem is the existence of a main project webpage (that all links on the net point to..for non 'github aware' users) that is http only. Everything from there down is broken if you were a malcious actor - it's party time starting with the non https site.

3) the arguments here 2 years ago that security and https and signing and such are not important have changed drastically since then with revelations about spy agencies, hacking groups, ransomware organizations, etc. The world really is this nasty and this stuff (for something as basic as a person's entire commuication and livelyhood nexus embodied in a phone) is important.

[superlupo12]

Ad 1: I see the packages are signed, e.g.
````
keytool -list -printcert -jarfile open_gapps-arm-7.1-pico-20170814.zip
Signer #1:

Signature:

Owner: CN=opengapps.org, OU=Buildbot, O=Open GApps, L=Virtual, ST=UTC, C=EU
Issuer: CN=opengapps.org, OU=Buildbot, O=Open GApps, L=Virtual, ST=UTC, C=EU
Serial number: c8af387b5028b9fc
Valid from: Fri May 05 11:06:56 CEST 2017 until: Tue Sep 20 11:06:56 CEST 2044
Certificate fingerprints:
MD5: DE:D0:B0:C3:FE:1F:C2:70:2C:DA:80:5E:7E:E0:4B:C7
SHA1: A8:22:97:D2:96:DD:9B:1C:02:0A:EF:F7:98:10:1A:02:F0:00:3C:2E
SHA256: 07:64:B6:43:15:96:FA:94:5C:68:E5:BD:D8:A8:30:5E:2F:2C:97:78:90:C1:CC:87:DB:E5:4A:90:0E:B2:61:12
Signature algorithm name: SHA1withRSA
Version: 1
````
Unfortunately, I nowhere can find this certificate published somewhere by Open GApps so I cannot verify its integrity. @opengapps: It would be nice if you post the fingerprints somewhere like LineageOS does here: https://wiki.lineageos.org/verifying-builds.html
And also of course keep the private key private ;-)

[magicgoose]

First of all, it is not 'critical' system software

This is irrelevant if this software is being flashed from the recovery. A man in the middle can put whatever they want in there, and the installation process will unconditionally overwrite files even if they are normally only accessible to the system/root, thereby bypassing all the security measures of Android. (in other words, even if it's not intended as "system software", a MitM can make it "system software", simply because the installation process allows to patch arbitrary parts of the system partition)

GitHub does not support this currently on custom domains

perhaps it would make sense to have a mirror on a non-custom domain then.