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 159816 - CVE-2005-0758 bzgrep has security issue in sed usage
Summary: CVE-2005-0758 bzgrep has security issue in sed usage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: bzip2
Version: 4.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Ivana Varekova
QA Contact: Ben Levenson
URL:
Whiteboard: impact=low,source=redhat,reported=200...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-08 09:51 UTC by Mark J. Cox
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version: RHSA-2005-474
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-13 15:18:44 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:474 normal SHIPPED_LIVE Low: bzip2 security update 2005-06-16 04:00:00 UTC

Description Mark J. Cox 2005-06-08 09:51:00 UTC
+++ This bug was initially created as a clone of Bug #121514 +++

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

Also affects RHEL2.1, RHEL3

Comment 1 Josh Bressers 2005-06-16 17:58: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-474.html


Comment 2 David Eisenstein 2005-09-03 10:09:11 UTC
I am having a problem reconciling the bzip2-1.0.2-bzgrep.patch in an errata
srpm created for this bug (bzip2-1.0.2-11.EL3.4.src.rpm) and the same patch 
file in the srpm created for Fedora Core 3 (bzip2-1.0.2-13.FC3.1.src.rpm).

Line 8 of the bzip2-1.0.2-bzgrep.patch (dated Jun 7 07:12) in the RHEL 3 srpm
reads:
    +    j=${i//\\\\/\\\\}
but line 8 of bzip2-1.0.2-bzgrep.patch (dated Jun 8 10:08) in the FC 3 srpm
reads:
    +    j=${i//\\/\\\\}

Is one of these patch files incorrect?  And if so, which one?

Comment 3 David Eisenstein 2005-09-04 05:25:08 UTC
Please see attachment #118434 [details], from bug #158801.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SHA1sum of the attachment:
09e992a0e6bb50fa7387f927041a50994b4555c8  test-cases.tar.gz

Did a little testing on bzgrep.  Test scripts are in the attached
"test-cases.tar.gz".  Just untar the tarball, go to the test-cases/ directory
and run:

  $ ./doit.sh

That will display the results of RHEL 3's bzgrep and FC3's bzgrep on two 
test files (one of which has an embedded backslash in its filename) and 
pipe the bzgrep results into less.

My take on this is that the RHEL 3 bzgrep patch is more correct than the
FC3 patch.  In the FC3-patched version of bzgrep, the `\f' in the file-
name gets converted into a form-feed (^L) in the display lines, but
in the RHEL 3 version, the `\f' displays as `\f'.

The bash interpretation of ${variable//<pattern>/<replacement>} is certainly
not as intuitive as one might wish!

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

iD8DBQFDGntvxou1V/j9XZwRAo5pAJ9rv1IYXPQlCLyEZeIAvbOxZL4uVACgoozo
vVG9Vhmow55/TRUFZYcTQgU=
=My5q
-----END PGP SIGNATURE-----


Comment 4 Ivana Varekova 2005-11-29 14:15:15 UTC
The rhel4 version was not fixed properly - there is a typo in the patch
( the command 
    j=`printf "%s" "$i" | tr '\n' ' '`
 should be  
    j=`printf "%s" "$j" | tr '\n' ' '` ). So this bug is still present in rhel4.
I'm reopening this bug.

The test case is:
Create two bz2 archives one of them with name |; s|.*|echo bla 1>\&2|e; s|:|.bz2.
and use bzgrep command which will find some string in the previously mentioned file.

Comment 7 Red Hat Bugzilla 2006-02-13 15:18:45 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-474.html



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