Bug 211760 - CVE-2006-4334 Multiple vunabilities in gzip (CVE-2006-4335, CVE-2006-4336, CVE-2006-4337, CVE CVE-2006-4338)
CVE-2006-4334 Multiple vunabilities in gzip (CVE-2006-4335, CVE-2006-4336, CV...
Product: Fedora Legacy
Classification: Retired
Component: gzip (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Fedora Legacy Bugs
LEGACY, 3, 4
: Security
Depends On:
  Show dependency treegraph
Reported: 2006-10-22 01:44 EDT by ali
Modified: 2013-01-09 23:06 EST (History)
3 users (show)

See Also:
Fixed In Version: FLSA-2006-211760
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-13 03:09:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output of rpm-build-compare.sh (2.32 KB, text/plain)
2006-11-04 01:07 EST, David Eisenstein
no flags Details

  None (edit)
Description ali 2006-10-22 01:44:28 EDT
+++ This bug was initially created as a clone of Bug #207643 +++

Description of problem:
Google Security Team has dicovered multiple vunabilities in gzip 1.3.5. These
vunabilities are recorded as CVE-2006-4334, CVE-2006-4335, CVE-2006-4336,
CVE-2006-4337, CVE-2006-4338.

Version-Release number of selected component (if applicable):

Additional info:
These vunabilities are already fixed for Red Hats commercial linux
distributions. Where is the updated package for fedora core??

-- Additional comment from varekova@redhat.com on 2006-09-22 11:51 EST --
fixed in gzip-1.3.5-8.

-- Additional comment from michal@harddata.com on 2006-09-26 15:34 EST --
> fixed in gzip-1.3.5-8

gzip-1.3.5-8 is from rawhide and this update indeed showed up there
some time ago.  But for FC5 gzip-1.3.5-7.1.fc5 sits for a number
of days already in "testing" and released packages do not seem to be
forthcoming.  See bug 204676 for a description of attacks.

-- Additional comment from bressers@redhat.com on 2006-09-30 17:23 EST --
Ivana, it seems you forgot to push this one live, can you take care of it ASAP?

-- Additional comment from varekova@redhat.com on 2006-10-10 03:30 EST --
The update gzip-1.3.5-7.1.fc5 is pushed as final now.

-- Additional comment from redhat@popovich.net on 2006-10-12 16:22 EST --
gzip 1.3.5-7.1 was pushed 2006-10-02
gzip 1.3.5-7 was pushed 2006-10-10

Note that the 10/02 version is later than the 10/10 version.

Does 1.3.5-7.1 have the relevant fix?

Or does someone need to release a 1.3.5-7.2?

-- Additional comment from matsuu@gmail.com on 2006-10-12 22:51 EST --
gzip-1.3.3 also has these vulnerabilities. FC3 is affected. see RHSA-2006-0667

-- Additional comment from bugzilla@2006.kasperd.net on 2006-10-13 01:17 EST --
I noticed that 1.3.5-7.fc5 and 1.3.5-7.1.fc5 where made available for download
in the opposite order of being build. So which one should I be using?
Intuitively the extra .1 sounds like a higher version number. But
lexicographically .1.fc5 is before .fc5, and neither have an epoch. Maybe I
misunderstood the algorithm for comparing version numbers, is it documented

-- Additional comment from varekova@redhat.com on 2006-10-13 10:31 EST --
The problem with update is fixed by 1.3.5-8.fc5

-- Additional comment from bugzilla@2006.kasperd.net on 2006-10-14 20:03 EST --
I don't see any gzip-1.3.5-8.fc5
Comment 1 David Eisenstein 2006-10-22 02:34:11 EDT
Thanks a bunch, ali, for noticing this issue and adding this bug.  I don't
believe anybody has done any work on the gzip issue, so if you would backport
for FC3 and FC4, it would be most welcome!  :)

Thanks again!
Comment 2 Michal Jaegermann 2006-10-22 12:57:11 EDT
There is 
which works as a replacement at least for FC4.  It is practically
the same as what showed up later as an update for FC5.

As for a quoted comment "I don't see any gzip-1.3.5-8.fc5"
then this version was released on October 16.  It does not differ
from gzip-1.3.5-7.1.fc5, save a version markings, so presumably
this was done to make tracking easier between FC5 and FC6.

There are really no essential differences between various gzip
versions in use.
Comment 3 ali 2006-10-22 17:09:12 EDT
I've put up a SRPM and the patches I used to take gzip-1.3.5-6 to gzip-1.3.5-9
(the current version from HEAD) at http://www.cs.uwm.edu/~lomonaco/gzip.  The
version bumps in the changelog seem to be from rebuilds and the addition of the
CVE patches, atleast from FC4.

FC3 seems to have shipped with 1.3.3. I don't have access to any FC3 systems
though I'm sure the above mentioned SRPM will build on FC3.  Not sure the policy
on bumping versions on security fixes; seems to be the easiest route though.

Not sure what the next step is...
Comment 4 David Eisenstein 2006-10-28 17:09:00 EDT
Hi Ali, and Michal,

I apologize for not responding to your hard work before now.  (I started a
post here then lost it before I could hit the <SEND> button a couple of days
ago.  Argh!)  I will take what you have (after a little bit of review), build it
on the build server, and push it out to updates-testing.  (Jesse Keating, Legacy
Project lead, has recently given me the ability to push things.)

Documentation on how packages have in the past been submitted for pushing to
updates, Ali, can be found here, though it appears the Legacy project may be
in the process of making some changes to that process:
<http://fedoraproject.org/wiki/Legacy/QATesting> under "Submitting Packages."

The community has been talking about removing the "QA Publish" step, and just
accepting what folks propose as updated .src.rpm packages to be pushed to
updates-testing.  Because of this, and because of an IRC conversation I had
with Jesse Keating about it a day or two ago, I guess we will go ahead and skip
this step, though I personally will take a moment to look at what you've
submitted before adding it to Legacy's CVS and pushing it to updates-testing. 
In this way, Fedora Legacy will reduce the QA burden down to the level done by
the Fedora Core project, hopefully making it less cumbersome for contributors
like you to contribute.

Thank you both for your contributions and enthusiasm!  We really need it! :)
Comment 5 David Eisenstein 2006-11-04 01:02:12 EST
Hash: SHA1

Ali - looked over the .src.rpm you submitted and it was good.  Only made a
couple of changes to the spec file.  One of the changes was to change the
Name-Version-Release from 'gzip-1.3.5-9' to 'gzip-1.3.5-6.1.0.legacy' so

  1)  there would be no upgrade versioning problems when a FC4 user upgrades
      to FC5 ... that is, the versioning of gzip is
        - gzip-1.3.5-6     for FC4 (currently),
        - gzip-1.3.5-6.2.1 for FC5 gold, and
        - gzip-1.3.5-8     for FC5 (version that fixes these security bugs).
      Were FC4 users to install a 'gzip-1.3.5-9' package, then they would
      not be able to properly upgrade that package if they attempted to up-
      grade to FC5.

  2)  the package would be recognizable by its name as a Fedora Legacy
      package, rather than a package created by the Fedora Core developers/

One other change was to add your name (and email) to the changelog so that
you would get proper attribution for your work and so folks would know who
to contact if they had questions.  I added my name also, but goofed in ad-
ding my email; but the powers-that-be said it was probably okay -- this time.
("Just don't let it happen again!" said they.  hehe)

Attached is the output of the 'rpm-build-compare.sh' script on your pack-
age and my pacakge to see the differences.  The current .src.rpm can be
found here:


It is signed by my legacy package signature key, and it has an sha1sum of 
7ffd0ffa4b96e24511fc7c413b9a14fb9e18a69e  gzip-1.3.5-6.1.0.legacy.src.rpm

There are also i386 and x86_64 binary rpms in that directory tree, though
all these will be pushed (hopefully tonight) to updates-testing.

Am planning on getting the packages for FC3 ready also, and push them to
updates-testing at the same time.

Thanks again for your work, Ali!  :)

Version: GnuPG v1.4.3 (GNU/Linux)

Comment 6 David Eisenstein 2006-11-04 01:07:55 EST
Created attachment 140341 [details]
Output of rpm-build-compare.sh

Here is the output of the rpm-build-compare.sh script on the
gzip-1.3.5-9.src.rpm by Ali and the update gzip-1.3.5-6.1.0.legacy.src.rpm.

Oh, and if you're interested, the rpm-build-compare.sh script itself that
I was using can be found here:

Comment 7 David Eisenstein 2006-11-06 23:00:58 EST
FC-3 and FC-4 packages pushed to updates-testing.  Please test and report your
findings here.  Thanks!
Comment 8 Eric Jon Rostetter 2006-11-07 14:35:01 EST
Hash: SHA1
++VERIFY for FC3 X86_64
Downloaded packages:
gzip.x86_64 0:1.3.3-16.1.fc3.legacy
Package installed fine on a single machine.  Tested functionality on
two tar files (list contents, untar, create tar, compare results of
taring old and new archives, etc).  All functionality tested worked
as expected.
Vote for release for FC3 X86_64.  ++VERIFY
Version: GnuPG v1.2.1 (GNU/Linux)
Comment 9 David Eisenstein 2006-11-08 04:36:31 EST
Thank you, Eric!   :-)
Timeout reduced to 1 week.

Matthew Miller - do you feel that since FC3's gzip has been VERIFIED - that we
should go ahead and push it updates so it won't have to wait for FC4 to be voted on?

Jesse - any opinions?  Ali?
Comment 10 Jeff Sheltren 2006-11-09 08:09:33 EST
Hi David, I'll save you the trouble and verify for FC4 :)

Hash: SHA1

Verify for FC4 package from updates-testing

1cf4530543c8f7da0d331f11388bb7517fa013e4  gzip-1.3.5-6.1.0.legacy.i386.rpm

Signature OK
Installs OK
gzip and gunzip work as expected on a few test files

Version: GnuPG v1.4.5 (Darwin)

Comment 11 David Eisenstein 2006-11-10 06:48:38 EST
Thank you, Jeff.  These have been verified enough, so should be eligible 
for release to updates!  :-)
Comment 12 David Eisenstein 2006-11-13 03:09:48 EST
gzip packages pushed for FC3 and FC4, FLSA-2006-211760


Note You need to log in before you can comment on or make changes to this bug.