Perl Exposure to Zlib Vulnerability, Mitigation Strategy?

[dave_aiello]

I'm sure most of my fellow monks are aware of the Zlib "Double Free" Vulnerability. The maintainers of the library have stated that over 500 apps on many different platforms may be affected. These include several Perl modules (list is an excerpt of Zlib's list):

• perl-Compress-Zlib
• perl-GD
• perl-Gtk-Perl
• perl-HTML-Embperl
• perl-Msql-Mysql-modules
• perl-Qt

Are my fellow monks satisfied that this is the complete list of modules that are affected? If not, is there a more complete list, or can we build one here?

Have any monks begun to think about a risk mitigation strategy? By this I mean

• how to track when vulnerable modules are updated and
• how to ensure that updated modules are pushed out to all the boxes where Perl code is deployed?

Dave Aiello
Chatham Township Data Corporation

[Masem]

I would suspect that the only issue with perl modules is if the modules use static linking of zlib. Because the zlib bug is simply fixed by installing the corrected version, which has no API changes, modules with XS extension that dynamically link against zlib should be fixed when zlib is fixed.

The zlib bug is more of a hit to those that have static zlib linking. These need to be recompiled to be fixed, which can be more of a hassle as these programs tend to be larger (like the kernel or Mozilla).

-----------------------------------------------------
Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

[gellyfish]

It appears that the only XS component that has Zlib statically linked (That I could find anyway) is /usr/lib/perl5/site_perl/5.6.1/i686-linux/pdflib_pl.so (on my machine YMMV) which is used by 'pdflib_pl.pm' (there are also Python and Tcl versions on my machine) - so apart from this module simply rebuilding the Zlib shared library should fix the problem.

/J\

[webadept]

I just went through this with that PHP bug a while back, and now need to get with various ISP's to get them to upgrade. .. again... I'm wondering what is the consensis of those who deal with ISP's on a regular basis .. what is your expected hassle factor to get a security flaw like this fixed, and when is an ISP easier to leave than to deal with?

Glenn H.

[gellyfish]

I work for an ISP and, believe me, we would rather fix this stuff before customers start ringing up than ignore it - the PHP thing for instance was fixed before anyone noticed. I think you will find that this is the case with most ISPs, after all it is machines on their network that are going to get r00ted, but of course with the larger players there may be some delay if they have thousands of machines to update ...

/J\

[cjf]

what is your expected hassle factor to get a security flaw like this fixed, and when is an ISP easier to leave than to deal with?

At very most, an email or a phone call. If you alert them to the vulnerability and they don't fix it within a reasonable amount of time (3 days after notice is plenty), then I'd change immediately. I'd also be concerned if they weren't already on it by the time I contacted them.

Staying with a provider who doesn't pay attention to security is a very bad idea. It's often a lot of hassle to change hosts, but the tradeoff for better security and service is almost always worth it.