Bug#696621: hipercdecode: strange 50MiB variable in bss segment
Package: printer-driver-foo2zjs
Version: 20120510dfsg0-1
Severity: minor
Tags: security
File: /usr/bin/hipercdecode
Hi,
I notice some strange use of a large variable in hipercdecode.c:
> 148 unsigned char blk[50*1024*1024];
> 150 void
> 151 decode(FILE *fp)
> 152 {
> 225 // unsigned char blk[50*1024*1024];
> 230 rc = fread(&blklen, 4, 1, fp);
> 235 blklen = be32(blklen);
> 236 rc = fread(&blk, blklen, 1, fp);
This imposes a (somewhat arbitrary?) limit of 50 MiB of input.
The size of blklen is also not checked before fread() into blk:
$ ( printf '\x7f\xff\xff\xff\x00\x00\x00\x00\x7f\xff\xff\xff' ; cat
/dev/zero ) | /usr/bin/time /usr/bin/hipercdecode
RECTYPE 0 (len=2147483647,0x7fffffff cnt=1), Page 1
0.00user 0.17system 0:00.29elapsed 58%CPU (0avgtext+0avgdata
206784maxresident)k
0inputs+0outputs (0major+12960minor)pagefaults 0swaps
On a Squeeze system this shows ~200 MiB memory used (which was all the
free memory on that system); on Wheezy (with hardened eglibc) only ~50
MiB. So I assume it is overflowing something? But even with
pseudorandom input it does not seem to crash.
With blk defined in function scope, the program would have segfaulted
(due to exceeding stack memory?) and this seems to have been worked
around by moving it to global scope (to the bss segment of the process
image?)
After blklen is known, why not just malloc() a suitably large area from
the heap???
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-2-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Reply to: