PepperFlash binaries are obtained insecurely from Adobe without verification |
||||||||
Issue descriptionI was excited to read the Mac component Flash update postmortem at https://docs.google.com/document/d/1oQe7Xv0FPwkDuzygBsXUxKoZHTlA6pERfN2WeX2dPBs. Thank you for writing it! I made several suggestions in that doc and was pleased that they were well-received. One of the things I asked for was a link to the code responsible for getting Flash builds from Adobe and putting them in Google Storage. The postmortem doc now points to this script: https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/961b602b1a0c28f74c7164d6eaf4f45a360fd0f7/scripts/flash_updater.py Reading through that script, it’s apparent that we obtain PepperFlash binaries from Adobe via unsecured ftp without any verification. The FTP URLs look like ftp://sjftp.adobe.com/runtimebuilds/flashplayer/${release_name}/${version_str}/${platform}/Pepper%20Plugin_Raw%20Build.zip although that URL won’t work as-is because it doesn’t contain credentials, which are supplied externally to the script in a .netrc file. It concerns me that we obtain these bits from Adobe via a non-secure channel and don’t verify their authenticity in any way before shipping them to our users, who will run this executable code. As we saw in the Mac component Flash update postmortem, Macs are capable of (at least sometimes) verifying PepperFlash’s code signature. We, too, can perform this verification on our own before releasing these bits, to ensure that they are genuine and come from Adobe. I’m not sure if Adobe is signing PepperFlash for other platforms or if it would be possible to do similar validations there. An alternative that could be implemented identically for each platform would be to obtain these bits via a more secure mechanism such as https. This would require Adobe’s cooperation. Another alternative that wouldn’t require Adobe to alter its serving infrastructure would be to continue receiving these bits via insecure ftp, but to have Adobe provide expected hashes of the .zip files to us via a secure means. Our verification would then be to assert that the hashes of the files we receive insecurely from them match the expected hashes received securely.
,
Sep 21 2016
+Satoshi and Jeromie, from Adobe (context for what we discussed in today's sync).
,
Sep 22 2016
Hi wfh, would you mind giving me the exact file name which you say signed with SHA1?
,
Jan 3 2017
,
Jan 3 2017
Issue 678020 has been merged into this issue.
,
Jan 3 2017
Per laforge@'s discussion with Adobe, they could modify their pipeline to drop off the binaries to a gs bucket instead of the ftp site. So we can do the following steps step 1: -create a gs bucket so adobe could drop off the binaries step 2: -modify https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/master/scripts/flash_updater.py, switch the upstream from ftp to the new gs bucket I tried to create a bucket following instruction at https://chrome-internal.googlesource.com/infra/infra_internal/+/master/doc/troopers/playbook.md#Create-a-new-Google-Storage-Bucket-for-a-client to run 'cit bucket gs://chrome-adobe-flash-binaries-raw'. but got a 403. So adding troopers label for help with creating the new bucket. Would it be possible to create a gs bucket gs://chrome-adobe-flash-binaries-raw , with similar read permission to gs://chrome-adobe-flash-binaries/, and allow an external google cloud account created by Adobe to write?
,
Jan 18 2017
gs://chrome-adobe-flash-binaries-raw already exists but it does have a different acl than gs://chrome-adobe-flash-binaries-raw but some @adobe.com users can already write to it: > gsutil acl get gs://chrome-adobe-flash-binaries-raw [ { "entity": "project-owners-824709284458", "projectTeam": { "projectNumber": "824709284458", "team": "owners" }, "role": "OWNER" }, { "entity": "project-editors-824709284458", "projectTeam": { "projectNumber": "824709284458", "team": "editors" }, "role": "OWNER" }, { "entity": "project-viewers-824709284458", "projectTeam": { "projectNumber": "824709284458", "team": "viewers" }, "role": "READER" }, { "email": "182615506979@project.gserviceaccount.com", "entity": "user-182615506979@project.gserviceaccount.com", "role": "WRITER" }, { "domain": "google.com", "entity": "domain-google.com", "role": "READER" }, { "email": "govind@google.com", "entity": "user-govind@google.com", "role": "WRITER" }, { "email": "dimu@google.com", "entity": "user-dimu@google.com", "role": "WRITER" }, { "email": "samwon@adobe.com", "entity": "user-samwon@adobe.com", "role": "WRITER" }, { "email": "jeclark@adobe.com", "entity": "user-jeclark@adobe.com", "role": "WRITER" }, { "email": "smoriwak@adobe.com", "entity": "user-smoriwak@adobe.com", "role": "WRITER" }, { "email": "laforge@google.com", "entity": "user-laforge@google.com", "role": "OWNER" }, { "email": "kerrnel@system.gserviceaccount.com", "entity": "user-kerrnel@system.gserviceaccount.com", "role": "READER" }, { "entity": "project-viewers-753717416718", "projectTeam": { "projectNumber": "753717416718", "team": "viewers" }, "role": "READER" }, { "email": "ihf@google.com", "entity": "user-ihf@google.com", "role": "WRITER" } ] > gsutil acl get gs://chrome-adobe-flash-binaries-raw [8/1825] [ { "entity": "project-owners-824709284458", "projectTeam": { "projectNumber": "824709284458", "team": "owners" }, "role": "OWNER" }, { "entity": "project-editors-824709284458", "projectTeam": { "projectNumber": "824709284458", "team": "editors" }, "role": "OWNER" }, { "entity": "project-viewers-824709284458", "projectTeam": { "projectNumber": "824709284458", "team": "viewers" }, "role": "READER" }, { "email": "182615506979@project.gserviceaccount.com", "entity": "user-182615506979@project.gserviceaccount.com", "role": "WRITER" }, { "domain": "google.com", "entity": "domain-google.com", "role": "READER" }, { "email": "govind@google.com", "entity": "user-govind@google.com", "role": "WRITER" }, { "email": "dimu@google.com", "entity": "user-dimu@google.com", "role": "WRITER" }, { "email": "samwon@adobe.com", "entity": "user-samwon@adobe.com", "role": "WRITER" }, { "email": "jeclark@adobe.com", "entity": "user-jeclark@adobe.com", "role": "WRITER" }, { "email": "smoriwak@adobe.com", "entity": "user-smoriwak@adobe.com", "role": "WRITER" }, { "email": "laforge@google.com", "entity": "user-laforge@google.com", "role": "OWNER" }, { "email": "kerrnel@system.gserviceaccount.com", "entity": "user-kerrnel@system.gserviceaccount.com", "role": "READER" }, { "entity": "project-viewers-753717416718", "projectTeam": { "projectNumber": "753717416718", "team": "viewers" }, "role": "READER" }, { "email": "ihf@google.com", "entity": "user-ihf@google.com", "role": "WRITER" }, { "email": "adobeflashruntime@gmail.com", "entity": "user-adobeflashruntime@gmail.com", "role": "WRITER" } ] Is there a specific service account you'd like added to the ACL for -raw?
,
Jan 18 2017
Sorry I forgot to update this bug. I filed request in another bug bc this one is security restricted (https://bugs.chromium.org/p/chromium/issues/detail?id=678020) The bucket looks good. Thank you seanmccullough@! We are now waiting on Adobe to switch from ftp to gs bucket. Assign this bug to myself now, I will switch our flash pipeline to use google storage upstream.
,
Jan 25 2017
Switched our upstream to gs bucket. Mark as fixed. https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/325e7a9daae030ef3acc6dafb8927ceb2f1bc279
,
Jan 25 2017
The following revision refers to this bug: https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/325e7a9daae030ef3acc6dafb8927ceb2f1bc279 commit 325e7a9daae030ef3acc6dafb8927ceb2f1bc279 Author: dimu <dimu@google.com> Date: Wed Jan 25 21:44:00 2017
,
Jan 26 2017
,
Feb 23 2017
The following revision refers to this bug: https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/00be10598782e188ecdf4b87fae07884b89b89a4 commit 00be10598782e188ecdf4b87fae07884b89b89a4 Author: dimu <dimu@google.com> Date: Thu Feb 23 00:28:57 2017
,
May 4 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by wfh@chromium.org
, Sep 21 2016