Reported by Ludwig Nussel from SUSE: There is still another directory traversal bug that allows to escape the theme directory. Our package installs to /usr/share/gnump3d so you can access the whole /usr tree: http://localhost:8888/include/zlib.h?theme=../.. cu Ludwig --- And while we are already at it ... $ grepr -w /tmp ./bin/gnump3d-index: $lockfile = &getConfig( "lockfile", "/tmp/index.lok" ); ./bin/gnump3d-index: $cache = &getConfig( "tag_cache", "/tmp/tags.cache" ); ./bin/gnump3d2: $tag_cache = getConfig( "tag_cache", "/tmp/tags.cache" ); ./lib/gnump3d/plugins/search.pm: my $tagCache = &getConfig( "tag_cache", "/tmp/tags.cache" ); ./lib/gnump3d/tagcache.pm: $tagCache->setCacheFile( '/tmp/tags.cache' ); cu Ludwig
Fixes for the /tmp issues attached. tmpfile.diff - Change fallback default for tag cache to "". index.lok.diff - Remove unsafe /tmp lockfile usage.
Created attachment 72860 [details, diff] index.lok.diff
Created attachment 72861 [details, diff] tmpfile.diff
CVE-2005-3349 for the insecure files
CVE-2005-3355 for the directory traversal
Jeremy we're still waiting for the directory traversal issue but the patch should probably be available by tomorrow. CC'ing you already so you can be ready for disclosure on the 17th.
Created attachment 72928 [details, diff] gnump3d-traversal.diff Patch for the directory traversal.
Jeremy please attach an updated ebuild to this bug. Do NOT commit anything to Portage at this time.
Created attachment 73012 [details, diff] gnump3d-index.lok.diff
Created attachment 73013 [details, diff] gnump3d-tmpfile.diff
Created attachment 73014 [details, diff] gnump3d-traversal.diff
Created attachment 73015 [details] gnump3d-2.9.7-r1.ebuild
Arch security liaisons please test and report back on this bug.
Adding halcy0n for x86 because I dont have my x86 box close.
this looks on ppc64? Error The requested file /include/zlib.h couldn't be found. Please try returning to the index.
sparc looks ok.
Now public with the release of upstream 2.9.8 http://www.gnu.org/software/gnump3d/ Jeremy: please commit the 2.9.7-r1 with already-tested keywords (or if you prefer push 2.9.8 as ~ and we'll have arch retest this one)
with 2.9.7-r1, when starting it, i get the following: * Caching service dependencies ... [ ok ] * Starting gnump3d ... * Updating index of music files (may take a while for the first time) ... Undefined subroutine &main::removeLock called at /usr/bin/gnump3d-index line 194. [ ok ] other than that, it seems to work fine on amd64
2.9.7-r1 and 2.9.8 are both in portage now
CC'ing remaining arches to mark stable (alpha and ppc64) and unCC'ing arch security liaisons.
stable on ppc64
alpha done
Time for GLSA decision. We did a similar one in the past so I vote YES.
Yes, we need one. And it's more than just an update since the issues changed (tmpfile vulns in).
GLSA 200511-16
