That's a weak vulnerability but that's a security issue.
"The problem is that it is possible to launch "file://" URLs from within PDF files. This can be exploited to e.g. read arbitrary files on the system and send them to the attacker."
There is no known fixed version yet
Since this is a binary-only package, there's nothing we can do until Adobe release a new version.
upstream takes way too long... printing/security, since we can't fix this and we can't let a vulnerable package in the tree, what do you think of pmasking, at least until this is fixed, or even for removal? please comment.
acroread 8.1.1 for linux is out. I don't know if it fixes this.
8.1.1 issues a pop-up warning box using the PoCs I could find, asking the user to confirm the access request - so I guess that sorts ths issue out.
However 8.1.1 is only available in English; I'm reluctant to remove the old version until Adobe have released all the language variants (doesn't usually take them too long, once they've released the US English version). I don't think the issue is critical enough to remove stuff before replacements are available.
Any news on this one?
Sorry, none yet. Still waiting for Adobe to release it in other languages.
I presume they've gotten delayed, having to deal with http://www.adobe.com/support/security/advisories/apsa07-04.html
which looks like a Windows-only issue, to do with the way mailto: URIs are handled by IE 7. A PoC available here:
It does trigger Firefox on Gentoo, although it doesn't achieve anything here (not least because my FireFox isn't configured to handle mailto: URLs).
Either way it doesn't change the situation for us - we're still waiting for the translated 8.1.1 to appear (perhaps it'll be an 8.1.2 when the new issue is dealt with).
Seems like the multilingual versions of the next acroread are out so this package could be updated.
(In reply to comment #7)
> Seems like the multilingual versions of the next acroread are out so this
> package could be updated.
Thanks for the notification. printing, please provide updated ebuilds.
printing, please bump.
(In reply to comment #9)
> printing, please bump.
Sorry for the huge delay, an updated version of the ebuild is in CVS now:
It should also work on 64bit, by depending on seamonkey-bin to provide a working gtkembedmoz.so. That is not optimal but currently there's no other way since firefox-bin doesn't ship with a gtkembedmoz.so anymore. Though the mozilla herd is so kind and considers putting a xulrunner-bin into the tree for us.
Language support is again as complete as it was in acroread7.
The only known remaining problem so far are a few
scanelf: rpath_security_checks(): Security problem with relative DT_RPATH '.'
warnings while emerging the ebuild. If that doesn't hurt, I'd like to unmask acroread asap to get some further testing and finally getting it stable if no serious problems arise.
acroread-8.1.2 is in the tree and unmasked now, should be fine to go stable in a few days.
...] the update includes several important security fixes, among them a few of critical severity that could be remotely exploitable. [...
I'd say 8.1.2 should go stable asap.
amd64 and x86 please test and mark stable.
This one is ready for GLSA vote. I vote YES.
Rerating B2, filed.
See also http://secunia.com/advisories/28802
please add CVE-2008-0726 - i could not add it cause i dont have the propper permissions
Fixed in release snapshot.