3 ms·

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

48 points by adulau 12y ago

tptacek 12y ago
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.
- thaumaturgy 12y ago
  A lot of server-side virus scanners can unzip .lzo attachments in email by default. And nobody likes updating mail servers.
- userbinator 12y ago
  I'm trying to find more information on the LZO format, but http://www.oberhumer.com/opensource/lzo/lzodoc.php http://www.oberhumer.com/opensource/lzo/lzodoc.php is 404 and there's no actual specification of how the data is to be interpreted, which is a little disappointing (in contrast, zlib/deflate is described in RFCs.) The source is not all that clear either, particularly the implicit state machine stuff.
projct 12y ago
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-years-old-bug-myth.html http://fastcompression.blogspot.com/2014/06/debunking-lz4-20...

48 points by adulau 12y ago

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.

thaumaturgy 12y ago
A lot of server-side virus scanners can unzip .lzo attachments in email by default. And nobody likes updating mail servers.
userbinator 12y ago
I'm trying to find more information on the LZO format, but http://www.oberhumer.com/opensource/lzo/lzodoc.php http://www.oberhumer.com/opensource/lzo/lzodoc.php is 404 and there's no actual specification of how the data is to be interpreted, which is a little disappointing (in contrast, zlib/deflate is described in RFCs.) The source is not all that clear either, particularly the implicit state machine stuff.

projct 12y ago

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-years-old-bug-myth.html http://fastcompression.blogspot.com/2014/06/debunking-lz4-20...