Bug 128637

Summary: texinfo: install-info & bz2 files
Product: [Fedora] Fedora Reporter: Steve Grubb <linux_4ever>
Component: texinfoAssignee: Miloslav Trmač <mitr>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 4.8-9 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-16 05:22:12 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:
Attachments:
Description Flags
patch currently being tested none

Description Steve Grubb 2004-07-27 16:36:33 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4.2)
Gecko/20040308

Description of problem:
I was investigating some strange actions of install-info and started a
code review.

readfile calls open_possibly_compressed_file(). That function tries
opening the file with a number of different file extentions.
Eventually, it tries fopening a bz2 file. If that is successful, it
returns the FILE pointer, not a gzfile pointer.

readfile, then passes that descriptor to gzRead. I doubt that gzRead
can make heads or tails of a bzip2 compressed file. The problem is
that the zlib patch does not handle the possibility of bzip2 files.

There are 3 options as I see it:

1) remove the zlib patch. If this is done, full pathnames should be
used for the decompressors. Other security measures should be taken as
well.

2) Delete the fopen of the bzip2 file. In this way, only uncompressed
text or gzip'ed files will successfully open.

3) Add bz2 support. This involves using a void pointer to
open_possibly_compressed_file(), using a flag to branch to bzRead
instead of gzread, using bzReadOpen, adding -lbz2 to flags, adjusting
configure to locate it, and a new BuildRequires.

I suspect a malicious person could create bz2 files knowing that
install-info may crash on them.

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

How reproducible:
Didn't try

Steps to Reproduce:
1. Found in code inspection

Additional info:

Comment 1 Steve Grubb 2004-07-29 16:34:43 UTC
Created attachment 102287 [details]
patch currently being tested

Comment 2 Steve Grubb 2004-07-29 16:38:17 UTC
In case you are considering option #1, I have attached a patch that
uses full pathnames to the compressor/decompressors. Additionally,
gunzip can handle .Z uncompress files. So gunzip was substituted for
uncompress.

I am currently testing in this mode and do not see anymore problems
with install-info. I commented out the zlib patch at line 51 of the
spec file and added the attached patch.

Even if you may disagree with this approach, it is wiser to use full
paths for the info utility helpers. The man utility uses full paths,
so should info.

Comment 3 Tim Waugh 2004-07-29 17:25:34 UTC
I think they way forward is to fix the patch.  Is this actually
causing problems right now?  We don't ship any .bz2 info files as far
as I can see.

Comment 4 Steve Grubb 2004-07-29 18:34:34 UTC
It may be true that you do not ship bz2 info files, but that does not
precude others from doing it. Info files that are bzip2'd are smaller.
For example, tar.info.bz2 is 90007 while tar.info.gz is 115960. It
really does add up when you have hundreds of them.

If you do not like ripping out the zlib code, please use the fullpath
part for the info utility. I think it was the first hunk of the patch.
It might even be better to turn filesys.c into filesys.c.in and use
configure/autoconf to insert the full path like 'man' does.



Comment 5 Miloslav Trmač 2006-01-16 05:22:12 UTC
I have changed the zlib patch to restore popen () use;
gzipped files are handled with zlib, bzip2ed by piping from bzip2.

Thanks for your report.