Twenty year old vulnerability in LZO/LZ4 compression discovered

A bug in the reference implementation of the widely-used LZO compression algorithm has been discovered. The vulnerability has existed since 1994 and affects most implementations of the algorithm (including LZ4). The integer overflow can be used to execute malicious code, possibly remotely.

Heise: http://www.heise.de/open/meldung/Zwanzig-Jahre-alte-Luecke-in-Lempel-Ziv-Kompression-gefaehrdet-Linux-Nutzer-2240442.html

cf. Wikipedia: http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Oberhumer

The easiest way to identify whether your specific implementation is vulnerable is to determine the maximum chunk size that is passed to the decompress routine. If buffers of sixteen (16) megabytes or more can be passed to the LZO or LZ4 decompress routine in one call, then exploitation of the integer overflow is possible. For example, ZFS constrains buffer sizes to 128k. So, even though they use a vulnerable implementation of LZ4, an attack is not possible without a second bug to bypass the buffer size constraint.

The second easiest way is to identify the bit size of the count variable. If the count variable (for example, named ‘t’ in the Linux kernel code shown above) is 64bit, it would take such a massive amount of data to trigger the overflow that the attack would likely be infeasible, regardless of how much data can be passed to the vulnerable function in one call. This is due to the fact that even modern computers do not have enough RAM available to store the data required to implement such an attack.

However, there is a specific issue with the previous check. Validate that even if the count variable is 64bit in size, the value used is still 64bit when a length value is checked. If the actual length value is truncated to 32bits, the attack will still work with only sixteen (16) megabytes of data.

All users of FFmpeg, Libav, and projects that depend on them, should consider themselves at risk to remote code execution. Period. Please update your software from the FFmpeg and Libav websites, or refrain from using these applications until your distribution has an adequate patch.

It should be noted that certain Linux distributions package Mplayer2 with the base system by default. MPlayer2 is vulnerable to RCE “out of the box”. If your distribution packages MPlayer2 by default, be sure to disable the embedded media player plugin (gecko-mediaplayer) for your browser. Firefox/Iceweasel, Chromium, Opera, Konqueror, and other Linux-based browsers are vulnerable to RCE regardless of the platform/architecture when an MPlayer2 plugin is enabled.

As of today, June 26th, 2014, all LZO vendors have patches either available online, or will later today. Please update as soon as possible to minimize the existing threat surface.

Lab Mouse Security: http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html

A recent post on a security blog has claimed that LZ4 is affected by a subtle bug which could result in remote code execution on basically any machine using LZ4 algorithm. Given that LZ4 is installed on every modern Linux distro, including critically Android, that it is also part of modern file systems such as ZFS, shipped with FreeBSD and Illumos, and used within widely deployed databases such as MySQL, or big data nodes powered by Hadoop, it must be a pretty big deal.

At the end of the day, none of the known implementation of LZ4 is exposed to this risk. Basically, most user programs employ LZ4 for small data packet structure, way below the critical limit. Programs which generate and distribute large compressed blocks (notably the lz4c pos-x compression utility, distributed within Linux Distro) use the documented streaming format, which limits block size to 4 or 8 MB. Remove also from the list programs which never take “externally provided” data as input, they can’t be targeted either.

I’m also bitter at the bug finding misappropriation. The real identifier is Ludwig Strigeus, let’s make that clear. The long list of “credits” at the end of DonB article is another reason for caution : it happens I asked some of the influential big names listed there, and they told they barely heard about the guy. Fame by association ? Sure, please thank Linus Torvald for “coordinating and advising” on the issue.

RealTime Data Compression Blog: http://fastcompression.blogspot.fr/2014/06/debunking-lz4-20-years-old-bug-myth.html

I’ve received an answer from Don Bailey. He blames the situation on a lack of communication. OK. In an attempt to bring the discussion to a more neutral level, this post is dedicated at providing a hopefully clear, concise and factual description of the situation. I hope it will help the reader to properly assess the risk level.

  • There was a vulnerability, it was fully described by Ludwig Strigeus and tracked for correction on the LZ4 issue board
  • The vulnerability is fixed. Update is recommended for 32-bits applications
  • The vulnerability requires uncommon conditions to be exploitable:
    • Input data supplied by untrusted source
    • Large block sizes, preferably ~16MB hence beyond LZ4 file format specification
    • 32-bits only
  • The Linux Kernel version, which is different and supplied by LG, has this vulnerability too
  • Linux Kernel programs (which are the only ones to access kernel functions) do not match the conditions that would make it exploitable
  • The Linux Kernel version is nonetheless being fixed too, to avoid any future risk for future versions of the kernel

RealTime Data Compression Blog: http://fastcompression.blogspot.fr/2014/06/lets-move-on.html