In http://www.adobe.com/support/security/advisories/apsa09-03.html Adobe indicates a vulnerability in acroread, and suggests removal of the libauthplay dll in order to turn an exploitable weakness into an unexploitable crash. I suggest there should be an ebuild for acroread which simply removes those libs, and the current ebuild should probably get masked. Both of these are short term measures until a fix becomes available.
printing, since an update to acroread is not to be expected within the next two weeks, we should follow the recommendation and remove this file. There's nothing we can do about Flash Player though.
(In reply to comment #1) > There's nothing we can do about Flash Player though. The ebuild already does ewarn about potential security issues and suggest flashblock. The wording might be adjusted to point out the actual security issue, and an ebuild for flashblock might be added to portage to faciliate centralized installation in a multi-user-environment. So there is something that might be done, but it isn't much, and it's certainly no perfect solution.
CVE-2009-1862 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-1862): Unspecified vulnerability in Adobe Reader and Acrobat 9.x through 9.1.2, and Adobe Flash Player 9.x through 9.0.159.0 and 10.x through 10.0.22.87, allows remote attackers to execute arbitrary code via (1) a crafted Flash application in a .pdf file or (2) a crafted .swf file, related to authplay.dll, as exploited in the wild in July 2009.
I've committed acroread-9.1.3.ebuild to CVS. Official advisory update from Adobe is still missing right now though.
Arches, please test and mark stable: =app-text/acroread-9.1.3 Target keywords : "amd64 x86"
amd64/x86 stable, all arches done.
GLSA request filed by a3li.
(In reply to comment #2) > (In reply to comment #1) > > There's nothing we can do about Flash Player though. > > The wording might be adjusted to point out the actual security > issue Yikes... which one?? For the record, here is the current wording: ewarn "Flash player is closed-source, with a long history of security" ewarn "issues. Please consider only running flash applets you know to" ewarn "be safe. The 'flashblock' extension may help for mozilla users:" ewarn " https://addons.mozilla.org/en-US/firefox/addon/433" I'm open to suggestions on how that could be enhanced / cleaned up... I suppose I could change it to "long history of *serious* security issues" or something...
(In reply to comment #8) > (In reply to comment #2) > > The wording might be adjusted to point out the actual security > > issue > > Yikes... which one?? The one which, at the point of my opening the bug, was known to exist, was known to get exploited in the wild, was not patched, and was mentioned in the URL of this report. > For the record, here is the current wording: [...] The word "history" sounds to me like "has been buggy at the past, might well be buggy right now, although we don't know any specific issue yet". It's that last aspect I had an issue with, as there was a definite issue known at the time I wrote the ebuild, and as the time till the fix came around seemed rather long. > I'm open to suggestions on how that could be enhanced / cleaned up... Right now I'd leave it as is for 9.1.3, as there are no known issues with that one (yet), afaik. For the future I suggest that the moment you learn about a security issue, you change the ebuild to indicate a known and unfixed issue, and revbump it so users are more likely to learn about it. This way they can be extra careful until the fix comes along. Dunno if using ebuilds solely to communicate known vulnerabilities is a good idea, though, so I wouldn't be surprised if this suggestion gets rejected. > I suppose I could change it to "long history of *serious* security issues" or > something... Not necessary imho; anything less then arbitrary code execution wouldn't even warrant an elogged message.
(In reply to comment #9) > as there was a definite issue known at the time I wrote the ebuild, s/ebuild/bug report/; I guess when you wrote the ebuild, the issue wasn't known yet. And I did write no ebuild for flash, wouldn't dare to claim that honour.
(In reply to comment #9) > For the future I suggest that the moment you learn about a > security issue, you change the ebuild to indicate a known and unfixed issue, > and revbump it so users are more likely to learn about it. If you have time to write a patch for my ebuild every time a new security vulnerability is reported for adobe-flash, please submit the patches to me, I'll certainly try to include them. But I just don't have time to do this myself, nor do I think that it's very useful (see below) to spam users with a list of current security vulnerabilities. > This way they can be > extra careful until the fix comes along. This logic is a bit faulty. They should be "extra careful" ALL the time because of a demonstrated history of major security problems and the fact that even when a new vulnerability is noted, no one but Adobe can fix it, and this is basically what the ewarn text says. Or I hope it say that. Furthermore, I suspect that most users fall into one of 2 categories regarding adobe-flash: - Those who run flashblock and are very careful to only run applets they trust. They will not be more cautious if the ewarn text tells them exactly what vulnerabilities are currently known, because they are already being as cautious as they can. - Those who do not care and run flash all the time everywhere. If the current ewarn text won't make them more cautious, I really doubt anything will.
(In reply to comment #9) > For the future I suggest that the moment you learn about a > security issue, you change the ebuild to indicate a known and unfixed issue, > and revbump it so users are more likely to learn about it. This way they can be > extra careful until the fix comes along. Dunno if using ebuilds solely to > communicate known vulnerabilities is a good idea, though, so I wouldn't be > surprised if this suggestion gets rejected. If you suggest this for flash, you'd have to do it for all packages in the tree until there is a fix out there. And that just does not work this way(tm), no maintainer has the time to do that. Informing people is something we do using a GLSA. Please continue your conversation somehwere else, as it does not belong to this issue in particular, thanks.
GLSA 200908-04