GNU gzip - News: gzip-1.4 released [stable/security]

gzip-1.4 released [stable/security]

Item posted by Jim Meyering <meyering> on Wed 20 Jan 2010 07:12:49 PM UTC.

This is to announce a stable release of the gzip compression tools.
The most important change is the one that addresses CVE-2010-0001,
mentioned in NEWS below.

    http://www.gnu.org/software/gzip/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=gzip.git;a=shortlog;h=v1.4
or run this command from a git-cloned gzip directory:
  git shortlog v1.3.14..v1.4

Here are the compressed sources:
  ftp://ftp.gnu.org/gnu/gzip/gzip-1.4.tar.gz   (888KB)
  ftp://ftp.gnu.org/gnu/gzip/gzip-1.4.tar.xz   (600KB)

Here are the GPG detached signatures[*]:
  ftp://ftp.gnu.org/gnu/gzip/gzip-1.4.tar.gz.sig
  ftp://ftp.gnu.org/gnu/gzip/gzip-1.4.tar.xz.sig

To reduce load on the main server, use a mirror listed at:
  http://www.gnu.org/order/ftp.html

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact.  First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

  gpg --verify gzip-1.4.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys B9AB9A16

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.65.23-13e35
  Automake 1.11a
  Gnulib v0.0-3341-gb4349b9

./NEWS

* Noteworthy changes in release 1.4 (2010-01-20) [stable]

** Bug fixes

  gzip -d could segfault and/or clobber the stack, possibly leading to
  arbitrary code execution.  This affects x86_64 but not 32-bit systems.
  This fixes CVE-2010-0001.
  For more details, see http://bugzilla.redhat.com/554418

  gzip -d would fail with a CRC error for some valid inputs.
  So far, the only valid input known to exhibit this failure was
  compressed "from FAT filesystem (MS-DOS, OS/2, NT)".  In addition,
  to trigger the failure, your memcpy implementation must copy in
  the "reverse" order.