zoo contains exploitable buffer overflows

[Arjan van de Ven]

On Sun, 2006-02-26 at 19:09 -0500, Josh Bressers wrote:
> > 
> > As the FE zoo maintainer I've applied the security patch suggested on=20
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D183109
> > 
> > I'm not sure the security analysis here is right, but since the patch
> > seems harmless and zoo is exposed to external input via mail filters
> > such as amavisd-new I preferred to err on the side of caution.
> 
> The issue seems to exist.  You can get cause zoo to segfault upon archive
> creation (this is a new and different issue) by creating a very long
> directory path.
> 
> mkdir `perl -e 'print "A"x254'`
> cd `perl -e 'print "A"x254'`
> mkdir `perl -e 'print "A"x254'`
> cd `perl -e 'print "A"x254'`
> touch feh
> cd ../..
> zoo a arch.zoo `perl -e 'print "A"x254 . "/" . "A"x254 . "/feh"'`
> 
> This causes zoo to crash here:
> 
>     void parse (path_st, fname)
>     register struct path_st *path_st;
>     char *fname;
>     {
>        char tempname[LFNAMESIZE];       /* working copy of supplied fname */
>        char *namep;                   /* points to relevant part of tempname */
> 
>        char *p;
>        strcpy (tempname, fname); <== Buffer overflow
> 
> This points out that zoo is a very poorly written program.  Luckily with
> the new changes to gcc and glibc, these horrible stack buffer overflows are
> non issues.  Run the above commands, you'll see on FC5 it doesn't crash,
> libc catches it.


not just FC5; FORTIFY_SOURCE ought to have caught this one as well in
FC4 (and even in FC3 if you enabled it there)