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)
