[Bug 1531923] Re: [MIR] lz4

[Seth Arnold]

Hello, I reviewed lz4 version 0.0~r131-1 as checked into xenial. This
shouldn't be considered a full security audit but rather a quick gauge of
maintainability.

- I found two CVEs, CVE-2014-4715 and CVE-2014-4611. One may be specific
  to the Linux kernel implementation of lz4 decompression; the other was
  an integer overflow issue with unusual architectures.

  While the reporting was poor and lead to very frustrated upstream, Yann
  moved to integrate a fuzzing process into the build alongside other
  extensive test suites. Builds spend far more time testing than building.

- lz4 provides a very fast compression library and tool
- Build-Depends: debhelper
- Does not itself do networking, cryptography
- Does not itself daemonize
- No pre/post inst/rm
- No init scripts
- No dbus services
- No setuids
- No sudo fragments
- No privieged portions of code
- No udev rules
- No cronjobs
- New lz4 lz4c executables, unlz4 and unlz4cat symlinks
- One lintian error:
  E: liblz4-1: postinst-must-call-ldconfig
  usr/lib/x86_64-linux-gnu/liblz4.so.1.7.1
- Clean build logs

- No subprocesses spawned
- Memory management looked careful
- Files written to are under control of callers
- Logging looked careful
- No environment variables used
- No privileged operations
- No networking
- No cryptography
- No privileged portions of code
- No webkit
- No tmp files
- No PolicyKit
- Clean cppcheck
- Clean shellcheck

lz4 is carefully coded; similar to most codecs or compression algorithms
it's complicated code, but it has a good track record, responsive
upstream, proactive attempts to find and prevent security issues, and the
closest thing I found to a bug is a partially-implemented feature to allow
changing the default suffix away from .lz4:

- LZ4IO_compressMultipleFilenames() and
  LZ4IO_decompressMultipleFilenames() uses a hardcoded
  '+ 20' rather than + suffixSize + 1 + (optional slop space)
- MAXSUFFIXSIZE appears unused
- LZ4IO_decompressMultipleFilenames() hardcodes LZ4_EXTENSION length as
  '4' (via %4s format string)

None of this is security-relevant or even user-facing.

Security team ACK for promoting lz4 to main.

Thanks


** Changed in: lz4 (Ubuntu)
     Assignee: Seth Arnold (seth-arnold) => (unassigned)

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2014-4611

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2014-4715

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to lz4 in Ubuntu.
https://bugs.launchpad.net/bugs/1531923

Title:
  [MIR] lz4

Status in lz4 package in Ubuntu:
  Confirmed

Bug description:
  [Availability]
  OK

  [Rationale]
  needed for next APT release and to fix squashfs-tools depwait

  [Security]
  One CVE so far: http://www.cvedetails.com/product/28069/Yann-Collet-LZ4.html?vendor_id=13512

  [Quality assurance]
  Small compression library, should be easy to handle.

  No bugs in Debian, except for a packaging wish:
  https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=lz4;dist=unstable

  Upstream bugs seem OK, mostly wishes and used as a TODO list:
  https://github.com/Cyan4973/lz4/issues
  (some small issues in the lz4 tool in liblz4-tool, but nothing really important).

  [Dependencies]
  Satisfiable

  [Standards compliance]
  seems ok

  [Maintenance]
  Actively maintained in debian, also used by zfs and squashfs.

  Foundations is now subscribed to bugs for the package.

  [Background information]

  APT master has just landed support for lz4 compression using liblz4.
  As such, we need liblz4-1 and -dev promoted to main for the next APT
  release.

  I'm posting this ahead of the APT release so we can get this change
  reviewed in advance.

  Also, squashfs-tools is currently in depwait on liblz4-dev.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923/+subscriptions