New issue
Advanced search Search tips
Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression



Sign in to add a comment
link

Issue 645687: /opt/google/chrome/PepperFlash/libpepflashplayer.so is miising !

Reported by ser...@gmail.com, Sep 9 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0

Steps to reproduce the problem:
1. dnf update 
2. google-chrome-beta update 
3. no flash available 

What is the expected behavior?
package have /opt/google/chrome/PepperFlash/libpepflashplayer.so 

What went wrong?
dnf --disablerepo='*' --enablerepo="google*" repoquery --available  google-chrome-stable -l  | grep -i pepper
/opt/google/chrome/PepperFlash
/opt/google/chrome/PepperFlash/libpepflashplayer.so
/opt/google/chrome/PepperFlash/manifest.json

but not appears in beta neither in unstable package 

Did this work before? Yes in previous version google-chrome-beta-53.0.2785.92-1.x86_64 

Chrome version: Version 54.0.2840.16 beta (64-bit)  Channel: beta
OS Version: google-chrome-beta-54.0.2840.16-1.x86_64
Flash Version: Shockwave Flash 22.0 r0
 

Comment 1 by ser...@gmail.com, Sep 10 2016

The solution: 
http://superuser.com/questions/970130/cannot-install-npapi-flash-player-plug-in-in-google-chrome 
and 
https://support.google.com/chrome/answer/6213033?hl=en

but I'd like have flash_player_ppapi install in system that in all browser of all users ... this flash_player_ppapi also works in firefox.

Comment 2 by ligim...@chromium.org, Sep 20 2016

Labels: Needs-Bisect

Comment 3 by thomasanderson@chromium.org, Sep 22 2016

Cc: thestig@chromium.org thomasanderson@chromium.org

Comment 4 by thestig@chromium.org, Sep 22 2016

Cc: waff...@chromium.org
Components: Internals>Plugins>Flash
r414249 / working as intended?

Comment 5 by ser...@gmail.com, Sep 25 2016

No , I want flash installed just one time in all system, be system wild and not install in every profile of every user. This r414249 is in new beta and do exactly what I don't want, that is "Unbundle Flash on Linux". 

Thanks.

Comment 6 by ashej...@chromium.org, Sep 26 2016

Labels: -Needs-Bisect Needs-Feedback
@thestig: Hey, would you mind responding to comment#5 ?

I really appreciate your help. Removing bisect label for now, feel free to add if required.

Thank you!

Comment 7 by waff...@chromium.org, Sep 26 2016

Status: WontFix (was: Unconfirmed)
For many reasons, I don't think the decision to separately update Flash and Chrome ("unbundling") will be reversed, so in a technical sense this is working as intended and I'm going to mark the bug as such.

That being said, we understand that this is sub-optimal for many use cases. At this time we don't have a mechanism to install components system-wide, but this is a feature we've been looking at for a while and would like to have soon.

Comment 8 by stephane...@gmail.com, Oct 13 2016

With Wireshark I found that Google Chrome 54 downloads Flash 23.0.0.185 PPAPI for Linux from this URL:
http://redirector.gvt1.com/edgedl/release2/rpofl8ynzf9r05ca7iim67wdwf3t0zpuehwy3aswydc9g91q5c4iydolh9lt5toluyuq2phjg168mcvxxhntm3n79e4nw3mrx1j/23.0.0.185_linux_PepperFlashPlayer.crx
It would be fairly easy to catch the DNS requests for redirector.gvt1.com to return the IP of any server.

According to this page a CRX file is a ZIP file with the author public key and a SHA-1 signature of its payload:
https://developer.chrome.com/extensions/crx

I found this topic on Stack Exchange stating that SHA-1 is not considered collision resistant, so even if the public key of the author is known to Chrome beforehand and checked against the public key in the CRX file it would still be possible to manipulate the CRX file in a way that the signature matches the payload. Still, it would require a big computational effort:
https://crypto.stackexchange.com/questions/6506/is-sha-1-still-practically-secure-under-specific-scenarios/6510#6510

Is it possible that the update mechanism of Flash implemented in Google Chrome 54 could be vulnerable to MITM attacks? Or are they more safeguards I am missing here?

Comment 9 by waff...@chromium.org, Oct 13 2016

There are additional protections: prior to initiating the download, the update system learned the expected SHA-256 hash of the payload from the Omaha update-check (which is in turn protected by a signing protocol called CUP). We then verify that hash prior to doing anything else with the CRX file.

You can learn more at https://github.com/google/omaha/blob/master/doc/ServerProtocolV3.md if you are curious.

Sign in to add a comment