[<prev] [next>] [day] [month] [year] [list]
Date: Sat, 12 Jul 2014 15:43:08 -0600
From: "Don A. Bailey" <donb@...uritymouse.com>
To: oss-security@...ts.openwall.com
Subject: LMS-2014-07-10-1 - CloudFlare GoLang LZ4 Memory Corruption
Hello All,
Please find the bug report attached to this email.
Best,
Don A. Bailey
Founder / CEO
Lab Mouse Security
@InfoSecMouse
https://www.securitymouse.com/
#############################################################################
#
# Lab Mouse Security Report
# LMS-2014-07-10-1
#
Report ID: LMS-2014-07-10-1
Researcher Name: Don A. Bailey
Researcher Organization: Lab Mouse Security
Researcher Email: donb@...uritymouse.com
Researcher Website: www.securitymouse.com
Vulnerability Status: Reported
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 Cloudflare golz4 package prior to commit
199f5f7878062ca17a98e079f2dbe1205e2ed898 on github. There are no tags
or releases for this software package, so master must be used, or
a branch past the above commit id.
32bit variants of the package are critically affected.
64bit variants are deemed infeasible to exploit at this time, but still
affected by the vulnerability.
Lab Mouse Security has engineered reliable RCE payloads for test applications
that use golz4, but a "one-shot" exploit against golz4 is not currently
possible due to the memory layout of GoLang.
Criticality Reasoning
---------------------
Due to the way GoLang manages objects memory, there are multiple ways to
craft a reliable exploit against golz4 that will allow for RCE. It is
notable that Don A. Bailey designed his exploit to meet the following
conditions:
- bypasses ASLR
- bypasses NX
- portable to any target architecture (tested on 32bit: ARM, x86)
Against applications that the user does not have the source code for, a
corresponding memory disclosure vulnerability must be used to accurately
craft a malicious RCE payload.
DoS or OOW is always reliable with this exploit.
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.
LZ4_uncompress as well as LZ4_decompress_safe are vulnerable for LZ4 Core
releases prior to r119. LZ4_decompress_safe in releases for r119 and later
are still vulnerable on 64bit platforms, but considered not feasible or
practical to exploit - at this time.
Vulnerability Resolution
------------------------
Resolved.
References
----------https://github.com/cloudflare/golz4/commit/2dcef6a6aeec3ad36816c726fb1386460d27a466https://github.com/cloudflare/golz4/commit/199f5f7878062ca17a98e079f2dbe1205e2ed898
http://blog.securitymouse.com/2014/07/bla-bla-lz4-bla-bla-golang-or-whatever.htmlhttp://blog.securitymouse.com/2014/07/i-was-wrong-proving-lz4-exploitable.htmlhttp://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.
