a follow-up to this story.
[Edit 2] The below post was redacted right after the initial publication. Should you wish a much shorter, and arguably more neutral tone, summary of the situation, please consider reading the follow up.
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, and is also part of modern file systems such as ZFS, shipped with FreeBSD and Illumos, used too within widely deployed databases such as MySQL, or big data nodes powered by Hadoop, it must be a pretty big deal.
The article then makes a fairly good job at describing the conditions required to trigger that risk, but unfortunately, these explanations are scattered somewhere between the middle and the end of an overly long technical article, ensuring most readers will stop at the dramatic headline. The present article has the objective to counterweight those "high stakes" claims.
First, there is a problem of methodology. The author left a brief note on the LZ4 issue board, and then, without even listening the detailed explanations you'll find below nor engaging into mitigation activity, went alone towards advertising it to the widest possible audience just a few days later, creating exposition risks for the users. This is far short of an expected professional behavior from a security firm.
[Edit] : Later comments from DonB state that this situation is due to him not receiving notifications about answers being provided for him on the board.
Second, the author claims to have found this subtle risk through careful code study on its own. This is not true. The risk was identified by Ludwig Strigeus, the creator of µTorrent, quite some time ago. Ludwig made a very fine job at describing the risk. Instead of trying to make a headline, he proposed a solution for it. After multiple partial fixes, the risk was finally plugged recently (just a few days before DonB second "disclosure"). Why so much time you would ask ?
Well, because there was no real-world risk.
Let's now get into the technical details.
In order to use the vulnerability, a number of conditions must be met.
A first minor one is : it is necessary to work within a 32-bits environment. 64-bits is totally unaffected. That basically put most server-side applications outside of the risk zone.
Second, the attacker need to forge a special compressed block to overflow 32-bits address space. This is possible ... if the compressed block is something like 16 MB.
There is just a little problem with that : the legacy LZ4 file format is limited to 8 MB blocks. Any value larger than that just stops the decoding process. 8MB is not enough to trigger a problem. The newer streaming format is even stricter, with a hard limit at 4 MB. As a consequence, it's not possible to exploit that vulnerability using the documented LZ4 file/streaming format.
Well, you say, but what about programs which use their own, undocumented, format ?
Indeed, same condition applies. To be exposed to this risk, very large blocks of 16MB or larger must be read by the decoder.
Does that happen ?
Let's have a look at several high-profile programs using LZ4. ZFS ? Max block size is 128 KB. Lucene ? Typical index size is 16 KB. It could be a bit more, say 64 KB, that's still far short of the objective. zram maybe ? nope, 4 KB memory segments. Linux kernel ? The boot section has to decompress a multi-megabytes kernel into memory, surely it can match the limit ? Yes, it does, but it uses the LZ4 Legacy File format, which limits each block to 8 MB maximum. OK, maybe AAA games such as Guild Wars 2 ? nope, real-time protocol is the realm of short messages, the protocol itself doesn't allow anything beyond a few KB. And so on, and on.
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.
So sorry, this is not a "new heartbleed" situation the author seems to dream for.
Nevertheless, it's a good move to close this risk, just in case, in the future, one implementation may inadvertently wander into the area of "custom compression format using large blocks of > 8 MB on 32-bits system, and receiving data from untrusted external sources". Granted, this scenario stands in the low probability range. But that's nonetheless good to plug it. Finding a solution without undesirable side-effects took some time though, but that's finally the case within current LZ4 release available on Github and Google code.
It's one thing to tell there is a potential vulnerability that should be fixed, to ensure it does not become exploitable in the future. It's a totally different thing to pretend there is a dangerous RCE (Remote Code Execution) exploit currently active on the Internet, which is scary. DonB article cleverly conflates the two, implying the second to create a flashy headline, while disseminating some minor disclaimer elements throughout the long article to pretend, whenever necessary, having said the first. That's clever, but conflating gravity level to grab some free ad is not a respectful behavior from a security firm.
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 names listed there, and they told me they barely heard about the guy. Fame by association ? Sure, please thank Linus Torvald for "coordinating and advising" on the issue.
Finally, I'm also angry because security matters, a lot. Triggering too many alarms to grab a bit of fame is a good way to weaken the power of future alarms. You can guess that when every headline claim a "new heartbleed" situation, no one will pay attention to the real next one which will matter. And that's dangerous.
Anyway, should you feel nonetheless at risk now, please don't hesitate to update your LZ4 version. It's a good thing to do anyway, and as stated previously, the vulnerability was already patched.