CVE-2008-4957 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-4957): find_flags in gccxml 0.9.0 allows local users to overwrite arbitrary files via a symlink attack on a /tmp/*.cxx temporary file.
DEBIAN: http://bugs.debian.org/496391 FILES: find_flags CODE: http://dev.gentoo.org/~rbu/security/debiantemp/gccxml
Would it be sufficient to just remove the .cxx at the end? It generates the tempfile name from the following: TESTFILE="find_flags_temp$GCCXML_PID"
No, that would make it even worse. I'll have look into it later.
Mark, you could still symlink a .cxx-less file to /etc/passwd. Instead, I'd check if the file belongs to us, and if so, it's safe to use it (if an attacker can create that file with our user account, we're already owned...) touch /tmp/$TESTFILE.cxx if [ ! -O /tmp/$TESTFILE.cxx ] then echo "Something nasty is happening here. Quitting." exit -1 fi I don't know if there is a patch upstream (yet).
No patch in CVS. There are more symlink issues, also see bug: http://www.gccxml.org/Bug/view.php?id=8083
(In reply to comment #4) > Mark, you could still symlink a .cxx-less file to /etc/passwd. > Instead, I'd check if the file belongs to us, and if so, it's safe to use it > (if an attacker can create that file with our user account, we're already > owned...) > > touch /tmp/$TESTFILE.cxx > if [ ! -O /tmp/$TESTFILE.cxx ] > then > echo "Something nasty is happening here. Quitting." > exit -1 > fi I'm not entirely sure whether this is race condition safe, so I'd rather play safe and use mktemp (or maybe mktemp -d and place all temp files in there).
It's not a race condition; if the file belongs to you, you're not entering the if statement, if the file does not belong to you, the code snippet will exit; the touching does not change ownership. Still, mktemp is surely the right way to go.
(In reply to comment #7) > It's not a race condition; Right, found that out now as well, but ... > if the file belongs to you, you're not entering the > if statement This assumption seems to be false... > if the file does not belong to you, the code snippet will exit; But it will always be owned by the user, except for the case where there is an ordinary file (i.e. not a symlink) which is more than user-writable. Uninteresting case, though. My testings: # somebody who is not me creates a symlink before the program is run $ sudo ln -s foo bar $ ls -la lrwxrwxrwx 1 root root 3 2008-11-12 23:47 bar -> foo # program is run and uses your "checking code", i.e. calling touch $ touch bar $ ls -la lrwxrwxrwx 1 root root 3 2008-11-12 23:47 bar -> foo -rw-r--r-- 1 christian christian 0 2008-11-12 23:47 foo $ [[ -O bar ]] && echo "Yes, file is owned by me (err... wait.. it isn't....)" Yes, file is owned by me (err... wait.. it isn't....) As you can see, both touch and -O do dereference symlinks. Checking for symlinks first would introduce a race condition though... so... I don't see any simple solution besides mktemp. BTW: As there is no patch, this is rather [upstream] than [ebuild], imo.
Epic fail for me. OF COURSE the file is owned by the current user, as the "evil user" links to it so that the current user will destroy it. My test case was crap, we would need an additional statement to check for symlinking; no need to discuss this further as we both already agreed before that using mktemp is the way to go. As said before in our IRC conversation, I was awfully tired, too. Sorry. :(
cpp: *ping*
(In reply to comment #10) > cpp: *ping* > I'm waiting for upstream and a solution: http://www.gccxml.org/Bug/view.php?id=8083
They've got a fix now, changing status whiteboard to [ebuild].
Sorry, this took so long. I just added gccxml-0.9.0_pre20090516 to the tree, which has the fix and other goodies.
It seems gccxml_find_flags has been obsoleted (since it is missing from the latest source file). The MIPS script is not fixed, as stated in the upstream report. Is it being used on our mips architecture? Arches, please test and mark stable: =dev-cpp/gccxml-0.9.0_pre20090516 Target keywords : "amd64 arm ia64 ppc s390 sh x86"
x86 stable
ppc done
amd64 stable
All supported arches done, entering [glsa?]. I vote YES.
arm/ia64/s390/sh stable
mips / cpp herd, can you please give some feedback regarding comment 14. Is the MIPSpro/find_flags being used on mips?
YES as well, filed request
GLSA 200909-11
