Bug 159816

Summary:	CVE-2005-0758 bzgrep has security issue in sed usage
Product:	Red Hat Enterprise Linux 4	Reporter:	Mark J. Cox <mjc>
Component:	bzip2	Assignee:	Ivana Varekova <varekova>
Status:	CLOSED ERRATA	QA Contact:	Ben Levenson <benl>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4.0	CC:	bressers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	impact=low,source=redhat,reported=20040422,public=20050422
Fixed In Version:	RHSA-2005-474	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-02-13 15:18:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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