[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 9 Jul 2014 16:05:54 -0600
From: "Don A. Bailey" <donb@...uritymouse.com>
To: oss-security@...ts.openwall.com
Subject: LMS-2014-07-09-1: lz4-ruby Memory Corruption
Hello All,
Please find the bug report for lz4-ruby attached below. For reference,
please visit the following blog post that will demonstrate memory
corruption using the latest version of Ruby and the LZ4 Ruby gem.
http://blog.securitymouse.com/2014/07/the-lz4-two-hour-challenge.html
Best,
Don A. Bailey
Lab Mouse Security
Founder / CEO
@InfoSecMouse
https://www.securitymouse.com/
#############################################################################
#
# Lab Mouse Security Report
# LMS-2014-07-09-1
#
Report ID: LMS-2014-07-09-1
Researcher Name: Don A. Bailey
Researcher Organization: Lab Mouse Security
Researcher Email: donb@...uritymouse.com
Researcher Website: www.securitymouse.com
Vulnerability Status: Reported through general LZ4 disclosure
Reported by Yann directly to
https://github.com/komiya-atsushi/lz4-ruby/issues/9
Vulnerability Embargo: None
Vulnerability Class: Integer Overflow
Vulnerability Effect: Memory Corruption
Vulnerability Impact: DoS, OOW, RCE
Vulnerability DoS Practicality: Practical
Vulnerability OOW Practicality: Practical
Vulnerability RCE Practicality: Practical
Vulnerability Criticality: Critical
Vulnerability Scope:
All versions of the lz4-ruby package equal or prior to 0.3.2
32bit variants of the package are critically affected.
64bit variants are deemed infeasible to exploit at this time.
Lab Mouse Security has engineered reliable mem corruption payloads for any
application that uses lz4-ruby, regardless of where or how the app uses the
module in its code base.
ruby 2.1.2p95 was used in exploit development.
Criticality Reasoning
---------------------
The Ruby LZ4 gem uses an old version of the LZ4 base package by default.
When built, it fetches r113 from the Google Code repository rather than
the latest stable version.
Even though the Ruby LZ4 bindings use the LZ4_decompress_safe variant of the
decompression algorithm, it is still vulnerable to the same memory corruption
flaw that other "unsafe" variants are subject to.
This vulnerability is proven in the reference URL at the bottom of this
report.
Vulnerability Description
-------------------------
An integer overflow can occur when processing any variant of a "literal run"
in the affected function. When certain payloads are processed, a pointer to
an output buffer can be set to an address outside of the output buffer. Since
the attacker can specify exact offsets in memory, it is very easy to create
a reliable RCE exploit.
Ruby allocates a heap chunk for decompression of LZ4 payloads. While certain
platforms do not allow for direct RCE using a heap chunk memory corruption,
others may be susceptible to direct heap chunk instrumentation.
Regardless, using memory pressure techniques or other application influence
strategies, it may be possible to align payloads in memory in such a way that
the business logic of an application can be corrupted. This is a standard OOW
attack that may, in some cases, lead to RCE.
At the least, this is a very reliable DoS bug, which may affect web services
that use the LZ4 algorithm.
Vulnerability Resolution
------------------------
Resolved.
References
----------http://blog.securitymouse.com/2014/07/the-lz4-two-hour-challenge.html
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
