Bug 121514 - CAN-2005-0758 zgrep has security issue in sed usage
Summary: CAN-2005-0758 zgrep has security issue in sed usage
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gzip   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact: Ben Levenson
URL:
Whiteboard: impact=low,public=20050422,source=red...
Keywords: Security
Depends On:
Blocks:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-13 12:12:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker 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
[snip]
      if test $with_filename -eq 1; then
        sed_script="s|^[^:]*:|${i}:|"
      else
        sed_script="s|^|${i}:|"
      fi
      $grep $opt "$pat" | sed "$sed_script"
[snip]
done

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 et.al. 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
Ivana,

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. 
Ivana

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:
gzip-1.3-16.rhel2
gzip-1.3.3-10.rhel3
gzip-1.3.3-14.rhel4


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.

http://rhn.redhat.com/errata/RHSA-2005-357.html



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