Recently news of a vulnerability in the zlib library was released already cataloged under CVE-2018-25032 causing a buffer overflow when trying to compress a specially prepared character sequence in the incoming data.
In its current form, the researchers demonstrated the possibility of calling abnormal termination of the process, so it has not yet been studied whether the problem may have more serious consequences.
It is mentioned that the vulnerability it has manifested itself since zlib 1.2.2.2 and affects the current version of zlib 1.2.11. It is noteworthy that a patch fixing the vulnerability was proposed in 2018, but the developers paid no attention to it and did not release a corrective version (the zlib library was last updated in 2017).
This bug was reported by Danilo Ramos of Eideticom, Inc who he was on the prowl for 13 years before he was found! The bug was introduced in zlib 1.2.2.2, with the addition of the Z_FIXED option. The option forces the use of fixed Huffman codes. For rare entries with
a lot of distant matches, the pending buffer in which compressed data is written can be overwritten. That results in a corrupted output due to invalid distances, and may result in out-of-bounds access, crashing the app.
Vulnerability manifests if the input stream contains a large number of matches to pack, to which packaging is applied based on Huffman codes fixed. Under certain circumstances, the contents of the intermediate buffer in which the compressed result is placed may overlap with the memory in which the symbol frequency table is stored. As a result, the formation of incorrect compressed data and a crash due to writing outside the buffer boundary are observed.
Vulnerability it can only be exploited by a compression strategy based on fixed Huffman codes. A similar strategy is chosen when the Z_FIXED option is explicitly included in the code (an example of a sequence that causes a crash when using the Z_FIXED option). Judging from the code the Z_FIXED strategy can also be automatically chosen if the optimal and static trees computed for the data have the same size.
The solution here combines the distance buffer and the literal/length buffers into a single symbol buffer. Now three bytes dbuffer space is opened for each literal or length/distance consumed pair, instead of the previous two bytes this ensures
that the pending buffer cannot overwrite the symbol table, since the maximum compressed fixed code length/distance is 31 bits, and since there are four bytes of outstanding space for every three bytes of the symbol space.
It is not yet clear whether the conditions to exploit the vulnerability can match the Z_DEFAULT_STRATEGY compression strategy, which is applied by default.
Otherwise, the vulnerability will be limited to certain specific systems where the Z_FIXED option is explicitly applied. If so, the damage from the vulnerability can be very significant, as the zlib library is the de facto standard and is used in many popular projects, including the Linux kernel, OpenSSH, OpenSSL, apache httpd, libpng, FFmpeg, rsync , dpkg. , rpm, Git, PostgreSQL, MySQL, etc.
It is also mentioned that the selected parameters under which the vulnerability manifests itself when choosing the default compression strategy Z_DEFAULT_STRATEGY. Under real conditions, the attack is still considered unlikely, since exploitation using the revealed sequence requires setting the memLevel parameter to 1, while level 8 is selected by default.
An example of a lock sequence when "deflateInit2(&strm, 7, Z_DEFLATED, 15, 1, Z_DEFAULT_STRATEGY)" is called (level=7, windowBits=15, memLevel=1).
Finally it should be mentioned that the solution is also not included still in packages offered by distributions, so you can track the release of fixes by distributions on these pages: Debian, RHEL, Fedora, SUSE, Ubuntu, Arch Linux, OpenBSD FreeBSD, NetBSD, plus the zlib-ng library is not affected by the problem.
If you are interested in knowing more about it, you can consult the details In the following link.