The algorithm is so wide-spread that it traveled to Mars
For as much as 20 years, all versions of the Lempel–Ziv–Oberhumer (LZO) algorithm for compression and decompression have been vulnerable to remote code execution and denial-of-service type of attacks.The flaw has lasted this long and has been perpetuated in all variants of the algorithm because every new implementation featured the core open-source code.
Don A. Bailey, founder and CEO of Lab Mouse Security, disclosed the technical details revealing that at fault was an integer overflow bug occurring when processing a Literal Run, a piece of data that is not actually compressed.
Since it was designed by Markus Oberhumer back in 1994, the LZO algorithm has gained popularity because of the efficient compression it provided, and today it is widely used in various devices and systems.
It has been integrated into the Linux kernel, Samsung implemented it in some Android phones and even NASA added it to the Mars Curiosity Rover (which means that LZO made it to Mars). However, it is also present in projects for the regular user, such as OpenVPN, FFmpeg, Libav or MPlayer2.
To better understand how wide-spread the algorithm is, Oberhumer says that “if you do have a car, a mobile telephone, a computer, a console, or have been to hospital recently, there's a good chance that you have been in contact with our embedded data compression technology.”
Provided its pervasiveness, the risk presented by the vulnerability is significant. However, because LZO has been modified numerous times to adapt to open or closed systems, a potential attacker should have to build custom malicious payloads for each implementation.
Also, even if the risk of a denial-of-service attack does exist, this is not possible in all versions. In the case of remote code execution there are platform and architecture restrictions that should be taken into consideration by a threat actor before deploying an attack.
At the moment, all vendors should offer patched versions of the LZO, and users are advised to update as soon as possible.
According to Bailey, finding out if a specific implementation is vulnerable consists in determining the maximum chunk size processed by the decompression routine. In an unaffected version, only buffers lower than 16MB can be passed to the LZO or LZ4 decompress routine.
Bailey recommends that all users of FFmpeg and Libav, along with all projects depending on them, should update their software because there is the possibility of remote code execution. Not using them is also one way to avoid the risk.