Description of problem:

bzip2-1.0.3/bzip2recover.c copies argv[0] to a statically sized buffer
progName which is declared as:

 92 #define BZ_MAX_FILENAME 2000
 93
 94 Char inFileName[BZ_MAX_FILENAME];
 95 Char outFileName[BZ_MAX_FILENAME];
 96 Char progName[BZ_MAX_FILENAME];

here, in main():

344    strcpy ( progName, argv[0] );

If we trick argv[0] into being more than 2000 characters long, we can
overwrite arbitrary locations in heap following the progName[] buffer.
If compiler put buffers that store file names after this location,
the exploitation of the flaw could lead to arbitrary file overwrite,
however this does not happen.

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

At least FC-6 and RHEL-5 bzip2recover. Seems like the code originates from
mid-90's, so it likely affects other releases.

How reproducible:

Allways.

Steps to Reproduce:

$ DIR=$(perl -e 'print ((("x" x 200)."/") x 20)')
$ mkdir -p $DIR
$ ln -s $(which bzip2recover) $DIR
$ $DIR/bzip2recover
*** buffer overflow detected ***
  
Actual results:

In releases with FORTIFY_SOURCE, glibc catches the bug.
In other cases a random corruption on heap occurs, possibly causing
the program to receive a SIGSEGV signal.

Additional info:

This has no security implications, as is would need a victim to
voluntarily interact with the attack mechanism and all he would get
would be to execute commands as himself.