From $URL: A critical vulnerability exists in Adobe Flash Player 10.2.152.33 and earlier versions for Windows, Macintosh, Linux and Solaris operating systems (Adobe Flash Player 10.2.154.18 and earlier for Chrome users), Adobe Flash Player 10.1.106.16 and earlier versions for Android, and the authplay.dll component that ships with Adobe Reader and Acrobat X (10.0.1) and earlier 10.x and 9.x versions for Windows and Macintosh operating systems. This vulnerability (CVE-2011-0609) could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being exploited in the wild in targeted attacks via a Flash (.swf) file embedded in a Microsoft Excel (.xls) file delivered as an email attachment. Adobe is not currently aware of attacks targeting Adobe Reader and Acrobat. Adobe Reader X Protected Mode mitigations would prevent an exploit of this kind from executing. We are in the process of finalizing a fix for the issue and expect to make available an update for Flash Player 10.x and earlier versions for Windows, Macintosh, Linux, Solaris and Android, and an update for Adobe Acrobat X (10.0.1) and earlier 10.x and 9.x versions for Windows and Macintosh, Adobe Reader X (10.0.1) for Macintosh, and Adobe Reader 9.4.2 and earlier 9.x versions during the week of March 21, 2011.
Adobe has release Flash 10.2.153.1. Please bump; thanks!
Bumped: www-plugins/adobe-flash-10.2.153.1 is in the tree and as usual can probably be marked stable any time since it's closed source and not really going to change. www-plugins/adobe-flash-10.2.153.1_p201011173.ebuild is also in the tree with this same fix, but should *not* go stable.
(In reply to comment #2) > Bumped: > Awesome, thanks! Arches, please test and mark stable: =www-plugins/adobe-flash-10.2.153.1 Target keywords : "amd64 x86"
works for me only with +nspluginwrapper
Looks ok on x86.
Oh yeah the good old it's not a regression train. Great. It's still bad, you know... x86 stable.
x86 stable. Thanks Andreas.
(In reply to comment #6) > Oh yeah the good old it's not a regression train. Great. It's still bad, you > know... x86 stable. That one is for another bug, sorry.
(In reply to comment #4) > works for me only with +nspluginwrapper You make a good point (here and on IRC). I've adjusted the ebuilds so that IUSE="+nspluginwrapper" since I believe most amd64 users with the 32-bit plugin will want it.
(In reply to comment #8) > (In reply to comment #6) > > It's still bad, you > > know... x86 stable. I believe that may still be a valid complaint in this case ;)
amd64 done, thanks Agostino
Thanks, folks. Added to existing GLSA request. See you next time! ;)
FYI, I have just p.masked <www-plugins/adobe-flash-10.2.153.1 because of this bug and also #360529 and #354207.
As long as #355191 isn't resolved, I don't think this is a good idea (from usability point of view, at least -- from a security one, no word from me)
This issue was resolved and addressed in GLSA 201110-11 at http://security.gentoo.org/glsa/glsa-201110-11.xml by GLSA coordinator Tim Sammut (underling).