Red Hat Bugzilla – Bug 128637
texinfo: install-info & bz2 files
Last modified: 2007-11-30 17:10:46 EST
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:
Created attachment 102287 [details] patch currently being tested
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.
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.
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.
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.