Bug 128637 - texinfo: install-info & bz2 files
Summary: texinfo: install-info & bz2 files
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: texinfo
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-07-27 16:36 UTC by Steve Grubb
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version: 4.8-9
Clone Of:
Environment:
Last Closed: 2006-01-16 05:22:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch currently being tested (1.48 KB, patch)
2004-07-29 16:34 UTC, Steve Grubb
no flags Details | Diff

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.


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