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 121514 - CAN-2005-0758 zgrep has security issue in sed usage
Summary: CAN-2005-0758 zgrep has security issue in sed usage
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gzip
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact: Ben Levenson
Whiteboard: impact=low,public=20050422,source=red...
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-22 10:46 UTC by Mark J. Cox
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version: RHSA-2005-357
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-13 12:12:56 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:357 normal SHIPPED_LIVE Low: gzip security update 2005-06-13 04:00:00 UTC

Description Mark J. Cox 2004-04-22 10:46:36 UTC
Al Viro posted to vendor-sec on Apr22:

zgrep contains the following gem:

for i do
      if test $with_filename -eq 1; then
      $grep $opt "$pat" | sed "$sed_script"

Aside of the correctness issues (try to use zgrep on files with e.g.
'&' in names), it leads to obvious fun when zgrep arguments had been
obtained by globbing in an untrusted place.  Even with standard sed we
have at least ;w<filename>; to deal with; for GNU sed there's also ;e;
on top of that (execute the contents of pattern space).  bzgrep is no
better - it's based on zgrep.

AFAICS, there are two solutions - one is to do what *BSD had done and
make grep(1) use zlib and libbz; then zgrep become links to
grep.  Another is to quote \, |, ; and newlines, which means extra
invocation of sed(1)...

Treating as embargoed.
Also affects bzip2 package; not creating extra bug at this time

Comment 4 Jeff Johnson 2004-05-11 14:31:33 UTC

*** This bug has been marked as a duplicate of 123012 ***

Comment 5 Mark J. Cox 2004-05-11 14:40:00 UTC
not a duplicate.  123012 refers to this bug as it applies to Fedora
Core; this bug refers to Red Hat Enterprise Linux.  The two will
probably require different solutions.

Comment 6 Josh Bressers 2005-04-04 13:30:02 UTC
Ping on this issue (now that there is a new maintainer)

Comment 7 Ivana Varekova 2005-04-05 13:37:36 UTC
The new version 1.3.3-10.rhel3 is in errata process now.
Ivana Varekova

Comment 8 Josh Bressers 2005-04-07 14:09:55 UTC

Can you verify if this issue also affects RHEL2.1 and RHEL4?  My notes say yes
but the bug doesn't specify.

Comment 9 Ivana Varekova 2005-04-07 14:24:08 UTC
Yes I will verify it. 

Comment 10 Ivana Varekova 2005-04-08 11:48:24 UTC
New RHEL2.1 and RHEL4 versions are in errata process now.
Ivana Varekova

Comment 11 Jay Turner 2005-04-25 14:06:33 UTC
Testing successful with the following:

Comment 12 Josh Bressers 2005-04-27 14:36:57 UTC
Lifting embargo

Comment 13 Josh Bressers 2005-06-13 12:12:57 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

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