After twenty years, a vulnerability in Lempel-Ziv-Oberhumer (LZO), an extremely efficient compression algorithm, has finally been patched. The flaw, a subtle integer overflow, existed for as long as it did because of the practice of recycling code in the development community.
Due to this, the vulnerability touches everything from open source libraries, mobile phones (Android on Samsung devices), and other embedded devices.
LZO was created in 1994 by Markus Oberhumer. The compression algorithm is optimized for speed, and it regularly outperforms zlib and bzip. The most common use is image data, which makes it perfect for applications that rely on video transmissions or projects that need to send large image files.
Since its creation, LZO has been used by many scientific and open source projects, including NASA's Rover, Curiosity, which just celebrated its Martian one-year anniversary this week.
Other uses for LZO include OpenVPN, MPlayer2, Libav, FFmpeg, the Linux Kernel, and Juniper's Junos IPSec. Moreover, LZ4 (a variant of LZO) is used for compression in ZFS (Solaris), Apache's Hadoop, and FreeBSD.
"With its popularity increasing, Lempel-Ziv-Oberhumer has been rewritten by many engineering firms for both closed and open systems. These rewrites, however, have always been based on Oberhumer's core open source implementation. As a result, they all inherited a subtle integer overflow. Even LZ4 has the same exact bug, but changed very slightly," wrote Don Bailey, founder and CEO of Lab Mouse Security.
Bailey discovered the flaws while manually auditing the LZO code. When asked if he was worried about someone going after NASA's Curiosity, he told CSO that was unlikely.
"NASA accepted the bug reports. I doubt it is vulnerable to an attacker. The Rover is so compartmentalized within NASA it would be hard to get to, and even harder to push a malicious payload to it. I doubt you could send it enough data to trigger the bug," he said.
"My bigger concern was actually the Rover accidentally triggering the bug by attempting to send corrupted data to NASA. If the camera took a corrupt snapshot for any reason, the [compression / de-compression] algorithm may accidentally trigger a fault causing the Rover to lock up. I know they have a heavily fault tolerant platform, but there are conditions where this may cause looped faults."
The vulnerability itself occurs when processing a Literal Run.
"A Literal Run is simply a way of finding and interpreting binary data. By attacking this functionality, an adversary can use this data to control a vulnerable application in an unintended way, potentially allowing for remote system compromise or elevated privileges," Bailey explained.
However, depending on what the attacker is targeting, they'll need to construct a malicious payload to fit each particular implementation of LZO. This limits the overall severity of the flaw, because the different overflow requirements mean that an attacker will have to put in some work to make something happen.
At the same time, that doesn't make attacks against LZO impossible. In fact, Bailey notes, it's possible to achieve remote code execution (RCE) on multiple architectures and platforms, but not all of them. The same can be said for Denial of Service (DoS), and adjacent object over-write (OOW).
"Because the LZO algorithm is considered a library function, each specific implementation must be evaluated for risk, regardless of whether the algorithm used has been patched," Bailey said.
"The scope of this algorithm touches everything from embedded microcontrollers on the Mars Rover, mainframe operating systems, modern day desktops, and mobile phones. Engineers that have used LZO must evaluate the use case to identify whether or not the implementation is vulnerable, and in what format."
On his blog, Bailey outlines the steps developers and administrators can take in order to determine if they're vulnerable to the flaws in LZO / LZ4. The easiest of which, is to determine the maximum chunk size that is passed to the decompress routine. If buffers of 16MB or more can be passed to LZO / LZ4, then that's a problem and exploitation is possible.
Furthermore, all users of FFmpeg, Libav, and projects that depend on them "should consider themselves at risk to remote code execution," Bailey adds. Moreover, Mplayer2 is vulnerable to RCE out-of-the-box, and it's packaged with some Linux distributions by default.
Answering questions for CSO, Trey Ford, global security strategist at Rapid7, said that businesses are likely to be impacted via mail gateway AV scanners.
"Though we haven’t seen any proof that these are vulnerable yet. In any case, IT departments should prioritize a patching strategy. We may also see this impact compression archive utilities and anti-virus tools, only time will tell. In a matter of time attackers will have both Denial of Service capabilities, and in some cases the ability to execute code remotely," he said.
"The frustrating thing is that this will likely be another textbook case of slow patching for embedded and consumer devices putting people at further risk for longer. Keep an eye open for mobile phone updates. I am particularly concerned about android devices that have carrier controlled patch cycles. For all users receiving ‘click here to see this video’ messages, that click just got scary."
Most of the open source projects that have implemented LZO have developed patches and are currently pushing them out to users. A full set of vulnerability reports are available here.
