Perl Exposure to Zlib Vulnerability, Mitigation Strategy?

dave_aiello has asked for the wisdom of the Perl Monks concerning the following question:

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

Comment on Perl Exposure to Zlib Vulnerability, Mitigation Strategy?

Replies are listed 'Best First'.
Re: Perl Exposure to Zlib Vulnerability, Mitigation Strategy? by Masem (Monsignor) on Mar 15, 2002 at 23:39 UTC
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 - mneylon-pm@masemware.com \|\| "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	[reply]
Re: Perl Exposure to Zlib Vulnerability, Mitigation Strategy? by gellyfish (Monsignor) on Mar 16, 2002 at 08:32 UTC
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\	[reply]
Re: Perl Exposure to Zlib Vulnerability, Mitigation Strategy? by webadept (Pilgrim) on Mar 16, 2002 at 10:08 UTC
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.	[reply]
Re: Re: Perl Exposure to Zlib Vulnerability, Mitigation Strategy? by gellyfish (Monsignor) on Mar 16, 2002 at 16:04 UTC
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\	[reply]
Re: Re: Perl Exposure to Zlib Vulnerability, Mitigation Strategy? by cjf (Parson) on Mar 17, 2002 at 20:45 UTC
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.	[reply]