Secunia Research has discovered two vulnerabilities in SWFTools, which
can be exploited by malicious people to compromise a user's system.
1) An integer overflow error within the "getPNG()" function in
lib/png.c can be exploited to cause a heap-based buffer overflow via
specially crafted PNG images.
2) An integer overflow error within the "jpeg_load()" function in
lib/jpeg.c can be exploited to cause a heap-based buffer overflow via
specially crafted JPEG images.
*** Bug 335576 has been marked as a duplicate of this bug. ***
Given a number of issues with swftools and the fact that it's a leaf; I'd say we could mask this; it's known for bundling part of xpdf and libart_lgpl, as well as having fortify-produced overflow warnings.
Are this problems valid with 0.9.1?
(In reply to comment #3)
> Are this problems valid with 0.9.1?
Yes. From the CVE reference:
"Multiple integer overflows in SWFTools 0.9.1 allow remote attackers to execute arbitrary code via (1) a crafted PNG file, related to the getPNG function in lib/png.c; or (2) a crafted JPEG file, related to the jpeg_load function in lib/jpeg.c."
Secunia states that it is fixed in git, but I am unable to find the commit.
I vote then to treeclean this if nobody finds the commit (as debian did long time ago with this package)
I am all for treecleaning it, but is this the commit:
As it have other opened bugs I would try to treeclean this anyway (if anybody really wants this maybe he volunteers as proxy maintainer as I have seen for other packages ;))
Please do not treeclean this package.
As far as I can see there are is not that much wrong with the package:
- this integer overflow (there is a patch available that fixes this issue ?!?)
- two wrong symlinks
- a bundled a copy of libart_lgpl (this is not longer true for 0.9.1)
- a bundled a copy of xpdf, which is not currently in the portage tree
Or is there an alternative for this package?
(In reply to comment #8)
> - a bundled a copy of xpdf, which is not currently in the portage tree
Seriously? That'd be dozens of security bugs then.
> Or is there an alternative for this package?
(In reply to comment #9)
> (In reply to comment #8)
> > - a bundled a copy of xpdf, which is not currently in the portage tree
> Seriously? That'd be dozens of security bugs then.
As in, if anything, this convinced me we need to get rid of this asap. Bug 386271, Bug 290430, and everything that's been fixed with existing GLSA, followed by most of the matching bugs with keyword 'poppler' since it's based off on XPDF.
The configure.in in Git seems to have an option to use poppler...
[ --enable-poppler link againist libpoppler], USE_POPPLER=true)
We use swftool to create swf from pngs. I don't know alternative tool for this (on Linux), poppler isn't an alternative (or i couldn't find any documentation about this) Is the security problem from upstream, or is it the ebuild?
upstream, it's not an ebuild fault
There's a development snapshot available with the option to use poppler ...
But it has more opened bugs:
And it fails to build with poppler support
Re-opening for security and drafting GLSA.
"Secunia states that it is fixed in git, but I am unable to find the commit."
I checked the git, and found that
6) Time Table
10/06/2010 - Vendor notified.
10/06/2010 - Vendor response.
13/08/2010 - Public disclosure.
In the git there are several int overflow fixes in lib/jpeg.c and lib/png.c
The git commit at 2010-06-15
I confess I can not test if the vulnerabilities are present after...
(I don't understand why this security problem is(was?) remote. Is there a remote service in swftools?)
I think it is a pity if we lose this package from Gentoo.
The problem is that it bundles an old version of xpdf, which is riddled with security flaws - it should use an external library instead. See https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
But according to Pacho, it fails to build with the support for Poppler pdf library :(
I agree, though. It's a shame to see it go. I personally use it to extract resources from swf's, so I'd be happy if it could be built without the pdf support. Maybe once a new version is released it could be re-added.
(In reply to comment #20)
> The problem is that it bundles an old version of xpdf, which is riddled with
> security flaws - it should use an external library instead. See
> But according to Pacho, it fails to build with the support for Poppler pdf
> library :(
> I agree, though. It's a shame to see it go. I personally use it to extract
> resources from swf's, so I'd be happy if it could be built without the pdf
> support. Maybe once a new version is released it could be re-added.
I don't like bundled libs as well, especially on source based distros. Perhaps i will try to build it without the lib, and post the result...
It would be good to know if the problem is only with the bundled xpdf or with the source code itself? If the later is true, I have no real chance to fix it, but thx xpdf dependency may be avoided more easy.
Created attachment 308035 [details]
This is the ebuild I tried, but fails when building poppler related code :S
Created attachment 308073 [details]
working without pdf
Created attachment 308075 [details, diff]
changes Makefile.in files
Sorry for the ugly comments, this was the first time I attached files.
The ebuild based on the last ebuild uploaded.
I found the poppler is found if the include path is given. It doesn't compile anyway, so I disabled the pdf2swf at all, and it's working.
I tested on amd64 and works. I tested png2swf and swfcombine. It works as well as with 0.9.1.
The pdf part has problem founding funtcions, maybe it's not compatible with the poppler version installed (app-text/poppler-0.18.4-r1)
I think it's better to have a working version without pdf than nothing at all.
Is anyone willing to proxy-maintain it?
(In reply to comment #27)
> Is anyone willing to proxy-maintain it?
I volunteer to proxy maintain it, please help me how to start this, contact me on email, or something. I think I am able to maintain it. Try to fix the pdf2swf compile, (maybe with the help of the developer) and everything will be ok.
Will go to bug 411265 to stop polluting this one ;), please attach all ebuilds+patches there
(Hi, I'm the swftools maintainer)
For the record, swftools uses a patched xpdf- it's quite different from the original xpdf, because swftools uses xpdf as a low-level PDF parser, not a rendering engine. Inkscape does something similar (and also contains parts of the xpdf sources).
The patched version also contains some fixes for bugs and security issues. (See the file lib/pdf/xpdf-changes.patch)
I am, however, working on getting swftools to link against poppler instead (with the help of Christian Wenzel.)
In the mean time, shipping it without pdf2swf sounds like a good idea.
Our Software relies on pdf2swf
So I compiled swftools from source and pdf2swf was built without any problems
I have app-text/poppler-0.16.7 installed, which is the latest stable version in my portage tree on our development server.
Maybe anyone can take a look into that.
Report a separate bug report please
(In reply to comment #31)
> Our Software relies on pdf2swf
> So I compiled swftools from source and pdf2swf was built without any problems
> I have app-text/poppler-0.16.7 installed, which is the latest stable version
> in my portage tree on our development server.
> Maybe anyone can take a look into that.
> Thank you!
It only compiles with the bundled xpdf. Matthias said it should be fine, but using the poppler would be more appropriate. This is why the pdf is disabled in the package in portage tree. You can compile it with the bundled pdf, but it has nothing to do with poppler, or poppler version.
This is off topic in this bug anyway.
By the way, as I wrote in comment no #19, this bug should be closed, this security problem has been fixed 2 years ago.
This issue was resolved and addressed in
GLSA 201204-05 at http://security.gentoo.org/glsa/glsa-201204-05.xml
by GLSA coordinator Sean Amoss (ackle).
(In reply to comment #34)
> This issue was resolved and addressed in
> GLSA 201204-05 at http://security.gentoo.org/glsa/glsa-201204-05.xml
> by GLSA coordinator Sean Amoss (ackle).
The GLSA resolution seems to be wrong now that swftools was reintroduced...
I had to read it twice, but:
Vulnerable versions <= 0.9.1
This is not exactly true, because the 0.9.1 was not affected in my opinion, but as 0.9.2 is in the portage it doesn't matter anymore.
(In reply to comment #36)
> I had to read it twice, but:
> Vulnerable versions <= 0.9.1
> This is not exactly true, because the 0.9.1 was not affected in my opinion,
> but as 0.9.2 is in the portage it doesn't matter anymore.
This bug was opened for the integer overflow vulnerabilities (identified as CVE-2010-1516) that are present in SWFTools 0.9.1 . The security issue in this bug has been fixed by removing the vulnerable package from Portage.
Information contained in GLSAs concern the stable tree and =media-gfx/swftools-0.9.2 is not stable on any arches at this time. Since there is not an unaffected stable upgrade path, the resolution recommending users unmerge media-gfx/swftools is correct.
However, I have added a note to the Resolution section of the GLSA informing users that an upgraded package is available, but not stable .
If there are vulnerabilities in software bundled with =media-gfx/swftools-0.9.2, then a new bug should be opened.
Sorry, I was wrong about the 0.9.1, there was a snapshot release between 0.9.1 and 0.9.2, which was fixed. (It was never included in the portage tree)