Clear questions and runnable code
get the best and fastest answer
Possible security problem in CPAN modules / CVE-2018-25032by cavac (Priest)
|on Mar 31, 2022 at 11:19 UTC||Need Help??|
Dear fellow Perl developers,
zlib, the compression library (also known as libz, deflate, compress on various systems) has a major flaw. While the bug is 17 years old, it only got attention in the last few days and weeks.
It even has a backdated CVE, because the bug was discovered years ago, but not fixed: CVE-2018-25032
See also: https://zlib.net/
It is known that this can cause at least denial-of-service attacks, but RCE (remote code execution) is not entirely out of the cards to my knowledge.
I have done a casual grep through my local CPAN mirror (yay for local mirrors!), which has given me a list of potentially vulnerable modules. There are over 90 of them. Yes, there are probably a few false negatives and a few false positive, as i didn't have time to go over each distribution in detail.
Please check your CPAN distributions for any use of zlib.c, libz.c, deflate.c, compress.c and similar variants and update as necessary. If at all possible, i would also recommend to switch to either the zlib provided by the operating system or at least coordinate with other CPAN authors to reduce the number of static copies of the zlib libraries spread all over CPAN modules.
The basic problem with distributing your own copy of a library like that is simple: Instead of it getting automatically updated with security fixes by the operating system or distribution vendor, it is up to YOU to track the library and provide security updates for your CPAN distributions. And you have to get the users to somehow not only update the operating system, you also have to get them to update their installed perl modules. While providing your own copies of C libraries is convenient, provides safety against incompatibilities with locally installed libraries and so on, in case of a security problem this can place a lot of extra burdens on the end user of your code. They suddenly have to go through every installed perl module, plus all the other non-perl programs to make their system secure again.
Perl isn't the only software environment that has this problem. Many other things also maintain local copies of these kinds of "simple but essential" libraries in their source code control. The list of potentially vulnerable programs is quite impressive. So far, i've seen mention (but have not confirmed it myself) of Chromium, Firefox, ImageMagick, Gimp, VLC, the Linux kernel among quite a few other programs. This stems from the fact the zlib/the deflate algorithm is used in, for example, the HTTP protocol and PNG image files.
Because the number of modules NOT using the zlib library installed with the operating system but instead using a static/local copy of the C-Files, a security problem like this (or worse) can take a long time to fix. It is up to all of us to work together and reduce the number of copies of potentially vulnerable code.
Thanks in advance for your help in solving this security problem.
Rene "cavac" Schickbauer
perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'