Attacker Value
Unknown
(1 user assessed)
Exploitability
Unknown
(1 user assessed)
User Interaction
Unknown
Privileges Required
Unknown
Attack Vector
Unknown
0

The LZO/LZ4 Integer Overflow Summary

Disclosure Date: July 03, 2014
Add MITRE ATT&CK tactics and techniques that apply to this CVE.

Description

Integer overflow in the LZ4 algorithm implementation, as used in Yann Collet LZ4 before r118 and in the lz4_uncompress function in lib/lz4/lz4_decompress.c in the Linux kernel before 3.15.2, on 32-bit platforms might allow context-dependent attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a crafted Literal Run that would be improperly handled by programs not complying with an API limitation, a different vulnerability than CVE-2014-4715.

Add Assessment

2
Technical Analysis

On Jun 26th, Don A. Bailey of Security Mouse published a blog detailing an integer overflow within
the LZO algorithm, specifically the LZ4 variant. The writeup can be found here:

http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html

PoC Example (Windows 32-bit):

#include "lz4.h"

char output[20<<20];
char input[20<<20];
int main(int argc, char* argv[]) {
  input[0] = 0x0F;
  input[1] = 0x00;
  input[2] = 0x00;
  for(int i = 3; i < 16800000; i++)
    input[i] = 0xff;
  LZ4_uncompress(input, output, 20<<20);
  return 0;
}

The LZ4 algorithm is vulnerable but in the real world no implementations are because either the
necessary vulnerable conditions aren’t dialed in correctly, or there is something else in place
(in the software or by operating system) that prevents the bug from exploitation. The flaw
requires the following conditions:

  • Must be in a 32-bit environment, which means all servers are safe from this issue.
  • The attacker need to forge a special compressed block to overflow a 32-bit address space and
    cause the decoding process to overflow, but it can only be done if the compressed block is
    something like 16MB or more. Some real-world implementations:
    * Legacy LZ4 file format is limited to 8MB, newer format is at 4MB.
    * ZFS = 128KB
    * zram = 4KB
    * Linux kernel = 8MB (uses LZ4 legacy)
    * Antivirus unpacking uses the official documented LZ4 (4MB max, 8MB if legacy format)
    * The latest lzo.c in FFmpeg is set at (10*1024*1024) + 16 (that’s 10MB + 16 bytes), and is allocated
    on the heap. However, matroskadec.c uses av_lzo1x_decode() with its own implementation and as
    far as I can tell there is no hard size limit.
  • The attack is most likely local

From the attacker’s perspective, it’s difficult to find apps out there that are actually vulnerable,
because so far we have not found one that exceeds 10MB, and we need something like 16MB. It’s even
more difficult to find them exploitable because of other memory corruption mitigations supported by
modern operating systems.

The fix in LZ4 can be found here (there is also a testing tool in fuzz.c):
https://github.com/Cyan4973/lz4/commit/da5373197e84ee49d75b8334d4510689731d6e90

CVSS V3 Severity and Metrics
Base Score:
None
Impact Score:
Unknown
Exploitability Score:
Unknown
Vector:
Unknown
Attack Vector (AV):
Unknown
Attack Complexity (AC):
Unknown
Privileges Required (PR):
Unknown
User Interaction (UI):
Unknown
Scope (S):
Unknown
Confidentiality (C):
Unknown
Integrity (I):
Unknown
Availability (A):
Unknown

General Information

Vendors

  • linux

Products

  • linux kernel

References

Advisory

Additional Info

Technical Analysis