Raising Lazarus – The 20 Year Old Bug that Went to Mars

Ouch. The bug here is simple. The LZO format has a block type for uncompressable data ("literal runs"). LZO implementations (all the ones Don Bailey looked at) keep a counter associated with literal runs that count NUL (00h) bytes. The counter can be made to grow quickly and eventually overflows. The LZO codecs Bailey looked at use that counter for a copy, and thus have a memory corruption flaw.

It's likely that anything you use that decompresses LZO (MPEG files are a good example) uses C code to do it, and not code in a higher-level language.

So you'd want to know any place your application accepts a file format that can use LZO, because that might be a potential memory corruption flaw in your application regardless of the language you built it in.

Memory corruption flaws are very bad; these are the bugs that often result in attackers being able to upload code to your server that is then executed. That vulnerability, once triggered on your site, is probably game-over for your whole data center/deployment environment.

This flaw won't be as easy to exploit as the Rails YAML bug will be, but to the extent that your code reuses a well-known LZO codec, there may be shrink-wrap exploits available soon.

I don't see anywhere that this is exploitable in the wild, given that most things LZ4 is used for use smaller block sizes than this.

http://fastcompression.blogspot.com/2014/06/debunking-lz4-20...