libpng: Multiple vulnerabilities

[fsbruva]

The bundled version of libpng has 17 known vulnerabilities, according to the NIST National Vulnerability Database, including one with severity 10.0 (out of 10).

There are three options:

1. Accept the risk and keep using libpng 1.4.3
2. Upgrade to the latest libpng 1.6.36
3. Wait and upgrade to some future version of libpng

I recommend option 2, which has only two vulnerabilities listed. However, I could be swayed to hold fast until option 3, because one of the vulnerabilities is a severity 8.6 memory leak.

What is the selected option that I should prepare a PR for?

[mherger]

Now that's probably the most important of your reports. Would you have an assessment of how these vulnerabilities can be exploited with LMS? I guess this is for Image::Resizer (and Media::Scan?). Is the upstream fixed?

[fsbruva]

Media::Scan, yes, and Image::Scale use PNG. The two most severe exploits would allow attackers to execute arbitrary code through crafted PNGs (either standalone or embedded in audio files) during library scanning.
The upstream (latest is 1.6.32) has been fixed, and the memory leak is from improper tear-down when the pngcp command fails, see: pnggroup/libpng#269.

[mherger]

Image::Scale we use all over the place indeed. And a lot with files of unknown source (remote artwork).

We already did update that module for select platforms. But that probably didn't include all the security fixes you mention.

If you could provide a fix for this, that might be a good starting point.

[mherger]

Ugh... I tried to update Image::Scale on Windows before... andygrundman/Image-Scale#9

[fsbruva]

We already did update that module for select platforms. But that probably didn't include all the security fixes you mention.

The perl module is only as (in)secure as the underlying libraries.

If you could provide a fix for this, that might be a good starting point.

Will do. I'll also update giflib and libjpeg, to cover those bases.

Ugh... I tried to update Image::Scale on Windows before... andygrundman/Image-Scale#9

Have you been able to replicate the issue with Image::Scale 0.14?

[fsbruva]

Argh. I just remembered that libmediascan also depends on giflib. And since giflib has an API-breaking change between the 4.x.x and 5.x.x series (the library was made completely re-entrant and thread-safe, as well as fixing LOTS of bugs). Image::Scale is flexible enough to use both old and new API, but libmediascan is not.

I will leave giflib as is, and update it if/when libmediascan gets updated.