[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFkuX4v_w4Q-VDhu=qm2XVfWJLKsZopNajPu3TwGM8qH5is+6A@mail.gmail.com>
Date: Thu, 26 Jun 2014 12:53:18 -0600
From: "Don A. Bailey" <donb@...uritymouse.com>
To: oss-security@...ts.openwall.com
Subject: LMS-2014-06-16-2: Linux Kernel LZO
Hello All,
A vulnerability has been identified in the Linux kernel implementation of
the LZO algorithm. Please find the bug report inline.
Best,
Don A. Bailey
Founder / CEO
Lab Mouse Security
https://www.securitymouse.com/
#############################################################################
#
# Lab Mouse Security Report
# LMS-2014-06-16-2
#
Report ID: LMS-2014-06-16-2
CVE ID: CVE-2014-4608
Researcher Name: Don A. Bailey
Researcher Organization: Lab Mouse Security
Researcher Email: donb at securitymouse.com
Researcher Website: www.securitymouse.com
Vulnerability Status: Patched
Vulnerability Embargo: Broken
Vulnerability Class: Integer Overflow
Vulnerability Effect: Memory Corruption
Vulnerability Impact: DoS, OOW
Vulnerability DoS Practicality: Practical
Vulnerability OOW Practicality: Impractical
Vulnerability Criticality: Moderate
Vulnerability Scope:
All versions of the Linux kernel (3x/2x) with LZO support (lib/lzo) that
set the HAVE_EFFICIENT_UNALIGNED_ACCESS configuration option. Currently,
this seems to include PowerPC and i386.
Vulnerability Tested:
- Via btrfs
- Stand alone
Functions Affected:
lib/lzo/lzo1x_decompress_safe.c:lzo1x_decompress_safe
Criticality Reasoning
---------------------
While some variants of this LZO algorithm flaw result in Remote Code
Execution (RCE), it is unlikely that the Linux kernel variant can. This is
due to the fact that control of the memory region that is overwritten can
not be controlled in a fashion that will result in the overwrite of objects
critical to the flow of execution.
However, it may be possible to overwrite "business logic" data in certain
circumstances, by corrupting adjacent objects in memory. Linux's guard pages
should mitigate this, however.
Because RCE is impractical, Object Over Write (OOM) is only practical in
constrained scenarios (read: impractical), and DoS is practical, the
criticality level of this issue should be defined as Moderate.
Furthermore, a Moderate definition is needed because of the use of LZO in
btrfs, and the potential use of LZO in networking, opening up the potential
for remote instrumentation of this vulnerability. It is notable that SuSE
recently reported that they will start using btrfs by default later this
year.
Lastly, only certain platforms are affected, decreasing impact.
Vulnerability Description
-------------------------
An integer overflow can occur when processing any variant of a "literal run"
in the lzo1x_decompress_safe function. Each of these three locations is
subject to an integer overflow when processing zero bytes. The following code
depicts how the size of the literal array is generated:
if (likely(state == 0)) {
if (unlikely(t == 0)) {
while (unlikely(*ip == 0)) {
t += 255;
ip++;
NEED_IP(1);
}
t += 15 + *ip++;
}
t += 3;
As long as a zero byte (0x00) is encountered, the variable 't' will be
incremented by 255. Using approximately sixteen megabytes of zeros, 't' will
accumulate to a maximum unsigned integer value on a 32bit architecture. In
combination with the following code, the value of 't' will overflow:
copy_literal_run:
#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
if (likely(HAVE_IP(t + 15) &&
HAVE_OP(t + 15))) {
const unsigned char *ie = ip + t;
unsigned char *oe = op + t;
do {
COPY8(op, ip);
op += 8;
ip += 8;
COPY8(op, ip);
op += 8;
ip += 8;
} while (ip < ie);
ip = ie;
op = oe;
The HAVE_OP() check will always pass in this case, because the size check
within the macro will evaluate based on the overflown integer, not the value
of 't'.
This exposes the code that copies literals to memory corruption. An
interesting side effect of the vulnerable code shown above is that the
value of 'op' can point to a region of memory just before the start of 'out'.
It should be noted that the following code unintentionally saves all other
architectures from exposure:
#endif
{
NEED_OP(t);
NEED_IP(t + 3);
do {
*op++ = *ip++;
} while (--t > 0);
}
NEED_OP() correctly tests the value of 't' here, disallowing the potential
for overflow.
It should be noted that if 't' is a 64bit integer, the overflow is still
possible, but impractical. An overflow would require so much input data that
an attack would obviously be infeasible even on modern computers.
Vulnerability Resolution
------------------------
To resolve this issue, the HAVE_OP and HAVE_IP macros should be enhanced to
detect for integer overflow. This is the most reasonable and efficient
location for catching corrupted or instrumented payloads. By testing for
overflow here, an attacker is simply wasting time by forcing the function
to process a large amount of zero bytes.
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.
