Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157696 - Gzip vulnerabilities, CAN-2005-0758,0988,1228
Summary: Gzip vulnerabilities, CAN-2005-0758,0988,1228
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: gzip
Version: rhl7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Fedora Legacy Bugs
QA Contact:
URL: http://www.securitytracker.com/alerts...
Whiteboard: 1, 2, rh73, rh90
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-13 20:54 UTC by John Dalbec
Modified: 2007-04-18 17:25 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-10 23:50:23 UTC


Attachments (Terms of Use)

Description John Dalbec 2005-05-13 20:54:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

Description of problem:
05.19.17 CVE: Not Available
Platform: Unix
Title: Gzip zgrep Arbitrary Command Execution
Description: zgrep is used to invoke grep on gzipped and compressed
files. zgrep is reportedly affected by an arbitrary command execution
vulnerability. This issue arises due to insufficient sanitization of
user-supplied data. An attacker may execute arbitrary commands through
zgrep command arguments to potentially gain unauthorized access to the
affected computer. zgrep 1.2.4 was reported vulnerable.
Ref: http://www.securitytracker.com/alerts/2005/May/1013928.html 

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


How reproducible:
Didn't try


Additional info:

Comment 1 Pekka Savola 2005-05-26 05:41:02 UTC
The above is CAN-2005-0758.
[see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121514]

CAN-2005-0988 	Race condition in gzip 1.2.4, 1.3.3, and earlier when
decompressing a gzip allows local users to modify permissions of arbitrary files
via a hard link attack on a file while it is being decompressed, whose
permissions are changed by gzip after the decompression is complete.
[see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155745]

CAN-2005-1228 	Directory traversal vulnerability in gunzip -N in gzip 1.2.4
through 1.3.5 allows remote attackers to write to arbitrary directories via a ..
(dot dot) in the original filename within a compressed file.
[see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156266]

The above 3 problems should be in the RHEL release process now, but haven't come
out yet, at least.



Comment 2 Michal Jaegermann 2005-06-14 00:42:12 UTC
https://rhn.redhat.com/errata/RHSA-2005-357.html

Comment 3 Michal Jaegermann 2005-06-14 03:47:52 UTC
gzip-1.3.3-12.rhel3.src.rpm from an advisory mentioned in comment #2
recompiles on RH7.3 without any changes (save a release tag).  Results work too.

Comment 4 Jeff Sheltren 2005-07-13 23:34:59 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've created SRPMs using the patches from RHEL:

RH 7.3:
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-2.legacy.src.rpm
166e411f87dc2761d661bf1b08ba68a9c3444eaa  gzip-1.3.3-2.legacy.src.rpm

RH9:
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-10.legacy.src.rpm
2da74c3c37963ea1465f72695a7df56ee0dae285  gzip-1.3.3-10.legacy.src.rpm

FC1:
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-12.legacy.src.rpm
6e3fea19f448ef72cb2edfb14e529f579512f08a  gzip-1.3.3-12.legacy.src.rpm

FC2:
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-13.legacy.src.rpm
b8b1cc4e2b9d5d5bcdcb76d813bc6d898879e422  gzip-1.3.3-13.legacy.src.rpm

The patches are:
gzip-1.3.3-zgrep-sed.patch
gzip-1.3.3-gzip-perm.patch
gzip-1.3.3-gunzip-dir.patch

and should fix CAN 2005-0758, 2005-0988, and 2005-1228 respectively
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC1aT9Ke7MLJjUbNMRApELAKCO4emY2flJBpp6lcaRAFFzZRFrZwCeODI9
T6567QHIeXlcPeORmC8xUQ8=
=+vkT
-----END PGP SIGNATURE-----

Comment 5 Pekka Savola 2005-07-14 07:44:22 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA w/ rpm-build-compare.sh:

 - spec file changes good
 - source integrity OK
 - versioning could be changed later; I'd use
   gzip-1.3.3-1.1.legacy.src.rpm, gzip-1.3.3-9.1.legacy.src.rpm, etc.
   so that the number space is not exhausted.
 - patches similar to RHEL3 in most accounts, HOWEVER I noted the following
   difference:

- --- [legacy gzip-1.3.3-zgrep-sed.patch]
+++ [RHEL3 same patch]
10:33:53.000000000 +0300
@@ -21,7 +21,7 @@
      elif test $with_filename -eq 0 && { test $# -eq 1 || test $no_filename -eq
1; }; then
        $grep $opt "$pat"
      else
- -+      i=${i//\\/\\\\}
++      i=${i//\\\\/\\\\}
 +      i=${i//|/\\|}
 +      i=${i//&/\\&}
 +      i=`printf "%s" "$i" | tr '\n' ' '`

This difference seems substantial.  Therefore I'd ask what did you use as a
source for these patches?  If the zgrep-sed.patch was the same as in RHEL3,
I'd give all of these a PUBLISH.

2da74c3c37963ea1465f72695a7df56ee0dae285  gzip-1.3.3-10.legacy.src.rpm
6e3fea19f448ef72cb2edfb14e529f579512f08a  gzip-1.3.3-12.legacy.src.rpm
b8b1cc4e2b9d5d5bcdcb76d813bc6d898879e422  gzip-1.3.3-13.legacy.src.rpm
166e411f87dc2761d661bf1b08ba68a9c3444eaa  gzip-1.3.3-2.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFC1hewGHbTkzxSL7QRAvCIAKCOFJc4Itr28cuCOx11pYB8g/lSIACgvuQR
BzT1aQpI9O+uVLVxddaihv8=
=aWLU
-----END PGP SIGNATURE-----


Comment 6 Jeff Sheltren 2005-07-14 13:21:15 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It is from the RHEL4 package...
not sure why that would be different than RHEL3, but apparently it is.

I've put updated packages here which have two changes:
1) version numbers are updated like you mentioned
2) now using rhel3 patch instead of rhel4

RH 7.3:
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-1.1.legacy.src.rpm
db921b8916975a1cce8aae68509f3db35c4c0ab2  gzip-1.3.3-1.1.legacy.src.rpm

RH9:
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-9.1.legacy.src.rpm
2b93f34a0c7cdd083aef2786a3245ade678e0c27  gzip-1.3.3-9.1.legacy.src.rpm

FC1:
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-11.1.legacy.src.rpm
aef7a6eee33c512ead62a1cce9a238b99fed7297  gzip-1.3.3-11.1.legacy.src.rpm

FC2:
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-12.1.legacy.src.rpm
0095a8f25f80d4ff46508b2698acecd58a384bb0  gzip-1.3.3-12.1.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC1maYKe7MLJjUbNMRAsmMAJ9cLDYuQaRBy6A7fRDyrsBDZRHtDQCgxlOP
nu7SygIBikMARW69G4GXy1g=
=Uyi2
-----END PGP SIGNATURE-----

Comment 7 Pekka Savola 2005-07-15 12:27:36 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA w/ rpm-build-compare.sh:
 - source integrity OK
 - spec file changes minimal
 - patches verified to match RHEL3

+PUBLISH RHL73, RHL9, FC1, FC2

aef7a6eee33c512ead62a1cce9a238b99fed7297  gzip-1.3.3-11.1.legacy.src.rpm
db921b8916975a1cce8aae68509f3db35c4c0ab2  gzip-1.3.3-1.1.legacy.src.rpm
0095a8f25f80d4ff46508b2698acecd58a384bb0  gzip-1.3.3-12.1.legacy.src.rpm
2b93f34a0c7cdd083aef2786a3245ade678e0c27  gzip-1.3.3-9.1.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFC16unGHbTkzxSL7QRAvTKAJ47k9pKoJoBSTO9MJ5fmlUYRiHDPACgxBD/
x9+qDCRBvlUrLGDU2cPSwFE=
=4aVT
-----END PGP SIGNATURE-----

Comment 8 Tom Yates 2005-07-19 06:26:43 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


e502c04eba525ffc028597d89a561234a5e4677a
/var/cache/yum/fedora-legacy-testing/packages/gzip-1.3.3-9.1.legacy.i386.rpm

installs OK.  created a file of random data, gzip'ped it, renamed the .gz
file, gunzip'ped it with -N, sha1sum is unchanged and original name
restored.

+VERIFY RH9

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC3JzvePtvKV31zw4RAjLgAKCr0u35UznKNpc6WVKjHuB2mjQYmwCgqyq5
9l18yhl7vd/WwPX+cbSGW5c=
=pEBM
-----END PGP SIGNATURE-----


Comment 9 Pekka Savola 2005-07-19 19:10:20 UTC
I tested this on RHL73.  The basic functionality is OK, but I noted the
following difference w/ rpm-build-compare.sh:

--rw-r--r-- root    root             6411 /usr/share/info/gzip.info.gz
+-rw-r--r-- root    root               30 /usr/share/info/gzip.info.gz

At install, there was also a message:

$ rpm -Uvh gzip-1.3.3-1.1.legacy.i386.rpm 
Preparing...                ########################################### [100%]
   1:gzip                   ########################################### [100%]
install-info: warning: no info dir entry in `/usr/share/info/gzip.info.gz'

.. it appears that gzip.info page has been truncated for some reason, compared
to the previous version as shipped by RH?

Comment 10 Jeff Sheltren 2005-07-19 19:49:40 UTC
As far as I can tell, this is a build system issue.  I just ran an 'rpmbuild
--rebuild' on the 7.3 src rpm from updates-testing and the info file is the
right size in the resulting rpm.

Comment 11 John Dalbec 2005-07-19 20:17:42 UTC
My guess would be a missing buildrequires: texinfo.

Comment 12 Jeff Sheltren 2005-07-19 21:53:23 UTC
You're absolutely right.  I'm build new packages with texinfo buildrequires
right now.

Comment 13 Jeff Sheltren 2005-07-19 22:14:04 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, I built some new packages with the texinfo buildrequires which
should fix the problem with the info file.

Only change is adding 'BuildRequires: texinfo' (and bumping the release number)

RH7.3:
7d7d75996ab2d6a94835798ba09cd85139f3b7d6  gzip-1.3.3-1.2.legacy.src.rpm
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-1.2.legacy.src.rpm

RH9:
1e4c0dbc59ceb3d4290043ec6c15c4999524d6e9  gzip-1.3.3-9.2.legacy.src.rpm
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-9.2.legacy.src.rpm

FC1:
e029a76e81be925bda92fab8bf2812f8d1d1757d  gzip-1.3.3-11.2.legacy.src.rpm
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-11.2.legacy.src.rpm

FC2:
2d38445cc436a662fb7e6ccde3f6cf11d4a55155  gzip-1.3.3-12.2.legacy.src.rpm
http://www.cs.ucsb.edu/~jeff/legacy/gzip-1.3.3-12.2.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC3XskKe7MLJjUbNMRApgTAKCfY4xNvPsqNWpcL1Im0k549k7KFQCfSmOb
sMV2LysuO4cLS9jHoWX8Cic=
=jSKF
-----END PGP SIGNATURE-----

Comment 14 Pekka Savola 2005-07-20 04:37:40 UTC
I think adding buildreqs can be added by Marc without new packages.

In general, if this is about missing 'texinfo', this can be troublesome in
general, as I'm pretty sure only a couple of packages which ship info pages have
that dependency..

Comment 15 Pekka Savola 2005-07-20 04:49:04 UTC
New packages have been put to updates-testing.  I'd say this requires redoing
the RHL9 verify vote.

Comment 16 Tom Yates 2005-07-20 05:05:34 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

inasmuch as my verify was any use (did the issue impact functionality?),
here it is again:

7960019da89fbdee222e71b7d9884e6dc9ed3056 gzip-1.3.3-9.2.legacy.i386.rpm

installs OK.  created a file of random data, gzip'ped it (verified the
original file is gone), renamed the .gz file, gunzip'ped it with -N,
sha1sum is unchanged and original name restored.

+VERIFY RH9

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC3dtyePtvKV31zw4RAgs8AJ9BibdGlxPPMtgerKTYe1hke8FO2ACfYzBV
n14uejYsn38WRO1sAKnHMZw=
=lMD6
-----END PGP SIGNATURE-----


Comment 17 Pekka Savola 2005-07-20 15:21:31 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Check w/ RHL73.  Gzip and gunzip seem to work properly.  Info page installs
nicely this time.  Seems to work as intended; +VERIFY RHL73

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFC3mvNGHbTkzxSL7QRAv6KAKC1Kl8uYECzhqkF/gJct9ZooguGUQCgynD5
5v0EXT0KOjjz0OlWEI0KeVc=
=WLg2
-----END PGP SIGNATURE-----


Comment 18 Mike Gerber 2005-07-21 13:59:15 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

16a19e2142d83f1db86dbf5a9a5a0b4e35d50c92  gzip-1.3.3-1.2.legacy.i386.rpm

It works and no problems with the info page.

VERIFY +RHL73
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC36cWCjsw+mN5avkRAosSAKDCOkWTIdlsqM0dev5TGt28xM+RxACaA193
TYp4z7WI+N7bvQuBPFw3bes=
=2A3S
-----END PGP SIGNATURE-----


Comment 19 Pekka Savola 2005-07-21 18:06:37 UTC
Timeout is two weeks.

Comment 20 Pekka Savola 2005-08-06 04:04:11 UTC
Timeout over.

Comment 21 Marc Deslauriers 2005-08-10 23:50:23 UTC
Packages were released.


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