Bugzilla Bug 245765

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