From $URL: Critical vulnerabilities have been identified in Adobe Flash Player 10.2.159.1 and earlier versions (Adobe Flash Player 10.2.154.28 and earlier for Chrome users) for Windows, Macintosh, Linux and Solaris, and Adobe Flash Player 10.2.157.51 and earlier versions for Android. These vulnerabilities could cause the application to crash and could potentially allow an attacker to take control of the affected system. There are reports of malware attempting to exploit one of the vulnerabilities, CVE-2011-0627, in the wild via a Flash (.swf) file embedded in a Microsoft Word (.doc) or Microsoft Excel (.xls) file delivered as an email attachment targeting the Windows platform. However, to date, Adobe has not obtained a sample that successfully completes an attack. Adobe recommends users of Adobe Flash Player 10.2.159.1 and earlier versions (Adobe Flash Player 10.2.154.28 and earlier versions for Chrome users) for Windows, Macintosh, Linux and Solaris update to Adobe Flash Player 10.3.181.14. Adobe recommends users of Adobe Flash Player 10.2.157.51 and earlier versions for Android update to Adobe Flash Player 10.3.185.21. Fixed software already available.
Flash player 10.3.181.14 is on the way... It's a slightly less-straightforward bump than usual, thanks to the new 'flash-player-properties' utility and the plugin for KDE's 'kcm' framework. I'll let you know when it's in the tree.
Okay, committed! I think in this case, due to the large number of changes than usual for a flash-player bump, I'd like to wait a bit longer than usual for it to settle out before stabilizing. Perhaps even the full 30 days, for a change :) Plus I still have to reevaluate what to do for poor 64-bit users with no native plug-in in sight. So the good news is: Shiny new flash player! The bad news is: New license everyone has to accept before installing, and 32-bit only for now.
Great, thank you. The new version is working well here (amd64) after I reemerged nspluginwrapper. (In reply to comment #2) > I think in this case, due to the large number of changes than usual for a > flash-player bump, I'd like to wait a bit longer than usual for it to settle > out before stabilizing. Perhaps even the full 30 days, for a change :) > Hmm... Since at least one of these vulnerabilities is being exploited currently, would it be possible to do it sooner? How about 10 days? I am sure we'll hear if flash is broken on ~arch. ;)
(In reply to comment #3) > Great, thank you. The new version is working well here (amd64) after I > reemerged nspluginwrapper. Fixed the need to re-emerge nspluginwrapper in www-plugins/adobe-flash-10.3.181.14-r1 (Bug #367223) > (In reply to comment #2) > > I think in this case, due to the large number of changes than usual for a > > flash-player bump, I'd like to wait a bit longer than usual for it to settle > > out before stabilizing. Perhaps even the full 30 days, for a change :) > > > > Hmm... Since at least one of these vulnerabilities is being exploited > currently, would it be possible to do it sooner? How about 10 days? I am sure > we'll hear if flash is broken on ~arch. ;) Sure, 10 days without (major) bugs sounds fine to me.
amd64 here not sure if i should open a new bug... had the same problem as Tim in comment 3 did not re-emerge www-plugins/nspluginwrapper-1.3.0 and tried www-plugins/adobe-flash-10.3.181.14-r1 no luck. re-emerged www-plugins/nspluginwrapper-1.3.0 with no success, but noticed >>> Installing (1 of 1) www-plugins/nspluginwrapper-1.3.0 * Removing wrapper plugins... * Auto installing 32bit plugins... ls: cannot access /usr/lib64/nsbrowser/plugins: No such file or directory * Auto installing 32bit plugins... ls: cannot access /usr/lib64/nsbrowser/plugins: No such file or directory * Any 32bit plugins you currently have installed have now been I created /usr/lib64/nsbrowser/plugins and re-emerged www-plugins/nspluginwrapper-1.3.0 but got the same error ls: cannot access /usr/lib64/nsbrowser/plugins: No such file or directory during install. so I went crazy on my kbd by pressing 'arrow UP' followed by 'Enter' in another terminal during the re-emerge of www-plugins/nspluginwrapper-1.3.0 00:39:07 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:07 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:08 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:08 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:08 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:08 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:09 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:09 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:09 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:09 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:10 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:10 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:10 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:11 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:11 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:11 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins 00:39:11 localhost ~ # mkdir -p /usr/lib64/nsbrowser/plugins now flash is working
Thanks for 10.3 build, but I have a suggestion to either fork this to 32bit and 64bit or make it somehow possible to force only one architecture. Yesterday I did world update and didn't notice lack of 32bit and 64bit USE flags on new flash. Than today had to do a presentation using flash plugin [Adobe Presenter]. Than what? Nothing shows. I had to do a quick revert to 10.2. Luckily I had Internet connection there...
(In reply to comment #6) > Thanks for 10.3 build, but I have a suggestion to either fork this to 32bit and > 64bit or make it somehow possible to force only one architecture. > > Yesterday I did world update and didn't notice lack of 32bit and 64bit USE > flags on new flash. Than today had to do a presentation using flash plugin > [Adobe Presenter]. Than what? Nothing shows. I had to do a quick revert to > 10.2. Luckily I had Internet connection there... Same here (for a Flex application showcase)... nspluginwrapper is now hardmasked on all computer I control to avoid such surprise :-) I am desperate to see Adobe reproducing the same scenario as 10.2 version (and previous one). Will Adobe realize someday that 64 bit is now widely spread on Linux ?
(In reply to comment #5) > amd64 here > > not sure if i should open a new bug... > > had the same problem as Tim in comment 3 > did not re-emerge www-plugins/nspluginwrapper-1.3.0 > and tried www-plugins/adobe-flash-10.3.181.14-r1 > no luck. You could (and should) re-open bug #367223, and include the log recorded when you emerged adobe-flash-10.3.181.14-r1. (In reply to comment #7) > (In reply to comment #6) > > Thanks for 10.3 build, but I have a suggestion to either fork this to 32bit and > > 64bit or make it somehow possible to force only one architecture. > > > > Yesterday I did world update and didn't notice lack of 32bit and 64bit USE > > flags on new flash. Than today had to do a presentation using flash plugin > > [Adobe Presenter]. Than what? Nothing shows. I had to do a quick revert to > > 10.2. Luckily I had Internet connection there... > > Same here (for a Flex application showcase)... nspluginwrapper is now > hardmasked on all computer I control to avoid such surprise :-) In my testing, 10.3.181.14-r1 works perfectly well with nspluginwrapper on amd64. Please re-open and add build logs to bug #367223 so we can ensure that all 64-bit users can use this latest security fix with no surprises.
(In reply to comment #4) > > Sure, 10 days without (major) bugs sounds fine to me. Hi, Jim, folks. Are we able to move forward with stabilization? Thanks!
No one has reopened or commented further on bug #367223, so I consider that issue closed. There's also a new issue with bug #367281 - But it's not something I can fix in this closed-source application, so I don't consider it a block to stabilization here. So in summary, I think it's time to go ahead.
(In reply to comment #10) > > So in summary, I think it's time to go ahead. Great, thank you. Arches, please test and mark stable: =www-plugins/adobe-flash-10.3.181.14-r1 Target keywords : "amd64 x86"
x86/amd64 ok for me
x86 stable, thanks Agostino
amd64: ditto Ago
amd64 done. Thanks Agostino and Ian
Thanks, everyone. Added to existing GLSA request.
CVE-2011-0627 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0627): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via crafted Flash content, as possibly exploited in the wild in May 2011 by a Microsoft Office document with an embedded .swf file. CVE-2011-0626 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0626): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to execute arbitrary code via unspecified vectors, related to a "bounds checking" issue, a different vulnerability than CVE-2011-0623, CVE-2011-0624, and CVE-2011-0625. CVE-2011-0625 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0625): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to execute arbitrary code via unspecified vectors, related to a "bounds checking" issue, a different vulnerability than CVE-2011-0623, CVE-2011-0624, and CVE-2011-0626. CVE-2011-0624 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0624): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to execute arbitrary code via unspecified vectors, related to a "bounds checking" issue, a different vulnerability than CVE-2011-0623, CVE-2011-0625, and CVE-2011-0626. CVE-2011-0623 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0623): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to execute arbitrary code via unspecified vectors, related to a "bounds checking" issue, a different vulnerability than CVE-2011-0624, CVE-2011-0625, and CVE-2011-0626. CVE-2011-0622 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0622): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors, a different vulnerability than CVE-2011-0619, CVE-2011-0620, and CVE-2011-0621. CVE-2011-0621 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0621): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors, a different vulnerability than CVE-2011-0619, CVE-2011-0620, and CVE-2011-0622. CVE-2011-0620 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0620): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors, a different vulnerability than CVE-2011-0619, CVE-2011-0621, and CVE-2011-0622. CVE-2011-0619 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0619): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors, a different vulnerability than CVE-2011-0620, CVE-2011-0621, and CVE-2011-0622. CVE-2011-0618 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0618): Integer overflow in Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to execute arbitrary code via unspecified vectors. CVE-2011-0579 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0579): Adobe Flash Player before 10.3.181.14 on Windows, Mac OS X, Linux, and Solaris and before 10.3.185.21 on Android allows attackers to obtain sensitive information via unspecified vectors.
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).