| 1 |
On Thu, 2004-08-05 at 20:42, Sancho2k.net Lists wrote: |
| 2 |
> We're trying to figure out the risk that GLSA 200408-03 (libpng: Numerous |
| 3 |
> vulnerabilities) poses to our servers. The only production app we've |
| 4 |
> become concerned about that links to libpng (at this point) is mod_php. |
| 5 |
> We've patched the version of libpng up to 1.2.5-r8 but can't determine if |
| 6 |
> mod_php needs to be rebuilt to link against new libraries. |
| 7 |
|
| 8 |
Try something like this: |
| 9 |
|
| 10 |
# ldd /usr/lib/apache2-extramodules/libphp4.so | grep png |
| 11 |
|
| 12 |
If a reference to libpng.so or similar shows up then that would indicate |
| 13 |
that a recompile of mod_php isn't necessary (provided the referential |
| 14 |
integrity of the link is sound - see below). |
| 15 |
|
| 16 |
> So two questions - does our situation warrant running revdep-rebuild for |
| 17 |
> any reason? |
| 18 |
|
| 19 |
Most probably not. I'd be more concerned about binaries which link to |
| 20 |
and compile in libpng statically (off-hand, I do not know if any such |
| 21 |
packages exist in portage but if so then they would probably support |
| 22 |
USE="static") and revdep-rebuild will not help there anyway. I think the |
| 23 |
reasoning behind the advice to use revdep-rebuild is to deal with those |
| 24 |
who were running very old versions of libpng (<=1.2.7 for instance) and |
| 25 |
who could possibly break dynamically linked binaries during the upgrade. |
| 26 |
|
| 27 |
> And does mod_php carry any risk when the png USE flag is set? |
| 28 |
|
| 29 |
I don't believe there is any significant risk. The only specific comment |
| 30 |
concerning this has been on Slashdot; well I don't know how much weight |
| 31 |
you would attribute to such a comment but it seems to make sense ;) |
| 32 |
|
| 33 |
<quote="Snaapy (753650)"> |
| 34 |
The bug affects only loading of PNG images. One can make a specially |
| 35 |
crafted PNG image which has some invalid fields causing problems in the |
| 36 |
decoder. The invalid handling of these special error cases may cause an |
| 37 |
application crash or potential execution of arbitary code in the |
| 38 |
application which uses libpng. |
| 39 |
|
| 40 |
It is not possible to introduce malicious RAW image data to the encoder. |
| 41 |
And even if it was possible, you should be able to pump data directly in |
| 42 |
the encoder, which is not a usual case with dynamically generated |
| 43 |
images. So, your PHP site is safe. |
| 44 |
<quote> |
| 45 |
|
| 46 |
Regards, |
| 47 |
|
| 48 |
--Kerin Francis Millar |
Archives