

 Raising Lazarus – The 20 Year Old Bug that Went to Mars - adulau
http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html

======
tptacek
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
A lot of server-side virus scanners can unzip .lzo attachments in email by
default. And nobody likes updating mail servers.

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

