Common Vulnerabilities and Exposures assigned an identifier CVE-2008-4959 to the following vulnerability: geo-code in gpsdrive-scripts 2.10~pre4 allows local users to overwrite arbitrary files via a symlink attack on (1) /tmp/geo.google, (2) /tmp/geo.yahoo, (3) /tmp/geo.coords, and (4) /tmp/geo#####.coords temporary files. References: http://bugs.debian.org/496436 http://dev.gentoo.org/~rbu/security/debiantemp/gpsdrive-scripts https://bugs.gentoo.org/show_bug.cgi?id=235770 http://www.openwall.com/lists/oss-security/2008/10/30/2
Created attachment 322708 [details] Patch used by Debian Attached is the patch that was used by Debian gpsdrive maintainer. It is not the same as originally proposed one linked in the Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496436#14 However, it does not seem to address the issue completely (I tried to send this to Debian BTS, but my mail bounced, possibly because bug is already archived?): Patched version: TMP=`mktemp` STYLE=${TMP}.style COORDS=${TMP}.coords OUTWAY=${TMP}.way MAP=${TMP}.gif And later... curl -L -s -A "$UA" "$URL" \ [...] > $COORDS [ ... ] make_style > $STYLE [ ... ] curl -L -s -A "$UA" "$URL" > $MAP So even if $TMP is created in a secure way, other files are not. During the script runtime, local attacker may set up appropriate symlinks after $TMP has been created, but before > ${MAP,COORDS,STYLE}. (Well, even before get-code is run, but it's much harder to guess $TMP.)
Note that currently we ship the much older 2.09 version, but it looks like it uses a very similar script (possibly even identical). I will try and patch it up tomorrow... I also have a 2.10pre6 package I have been working on, will make changes there as well for when it's imported.
Yeah, I agree that the debian patch doesn't solve much if anything. ;( What do you suggest? We could make the temp files right before use, but there is still a race there. Something like: diff -Nur gpsdrive-2.09.orig/src/geo-code gpsdrive-2.09/src/geo-code --- gpsdrive-2.09.orig/src/geo-code 2003-04-28 08:32:48.000000000 -0600 +++ gpsdrive-2.09/src/geo-code 2008-11-10 15:33:43.000000000 -0700 @@ -248,11 +248,10 @@ # # Main Program # -TMP=/tmp/geo$$ -STYLE=${TMP}.style -COORDS=${TMP}.coords -OUTWAY=${TMP}.way -MAP=${TMP}.gif +STYLE=`mktemp -t gpsdrive.style` +COORDS=`mktemp -t gpsdrive.coords` +OUTWAY=`mktemp -t gpsdrive.way` +MAP=`mktemp -t gpsdrive.gif` UA="Mozilla/5.0" if [ "$GURL" != "" ]; then @@ -269,7 +268,7 @@ | head -n1 \ ` if [ "$URL" = "" ]; then - cp $COORDS /tmp/geo.google + cp -d $COORDS /tmp/geo.google error "Unable to lookup telephone number or name with Google" else URL="http://maps.yahoo.com/$URL" @@ -295,7 +294,7 @@ fi if [ $DEBUG -gt 0 ]; then - filter="tee /tmp/geo.yahoo" + filter="tee `mktemp`" else filter=cat fi Thoughts?
(In reply to comment #3) > Thoughts? Few quick... - your patch is missing couple of Xs ;) $ mktemp -t gpsdrive.style mktemp: too few X's in template `gpsdrive.style' - I'm not sure about the tee part. If I remember the script correctly, purpose of that tee filter was to save output of some command in an easy to find file. If only mktemp is used, it will generate some random name that may not be easy to find in /tmp in the crowed of other files with similar names (if you run scrip repeatedly). Maybe something like: teeoutput=`mktemp -t` filter="tee $teeoutput" [ command ] cp -d $teeoutput /tmp/geo.yahoo As for the races, mktemp will create the file, so other user can not replace it with malicious symlink, so it's fine.
Created attachment 326896 [details] patch for issue Here's a proposed patch. Sorry for the lengthly delay here... this fell off my radar. ;(
What about something like: TMP=$( mktemp -t -d "geo-$(id -un)-XXXXXXXX" ) if [ $DEBUG -gt 0 ]; then echo "Using temporary directory: $TMP" fi STYLE, COORDS, OUTWAY and MAP will need to change to $TMP/geo.<suffix> And probably at the end: if [ $DEBUG -eq 0 ]; then rm -rf "$TMP" fi so it does not leave lots of temp files around on each run? It should also make it easier to find all debug files related to one program run and should make this a bit multi-user friendly.
Created attachment 327065 [details] patch for issue. ok, I like that... except that it's setup so if debug is set it copies some of the needed files to /tmp/ to help with debugging, so there should be no need to keep any of them around aside from that at the end. How about this patch?
Even better. Just that "cp -d $COORDS /tmp/geo.something" is not too mutli-user friendly, but should be safe. Long term solution may be to move to some ~/.gpsdrive dir instead of /tmp.
Affected scripts were dropped upstream: http://gpsdrive.svn.sourceforge.net/viewvc/gpsdrive?view=rev&revision=2204
Interesting. So, should we: - Just drop the scripts ourselves. - Push fixes for this and the other outstanding item, and wait for more. - Wait a bit and see if there are more we should fix. Thoughts?
So there are 4 CVEs for various temporary file issues in gpsdrive: - CVE-2008-4959 (bug #470241) - fixed upstream by dropping geo-code - CVE-2008-5380 (bug #475478) - fixed upstream by dropping geo-code and geo-nearest - CVE-2008-5703 (bug #481702) - fixed upstream by dropping gpssmswatch and fixing splash.c - CVE-2008-5704 (bug #481703) - fixed upstream by fixing unit_test.c I guess the main question here is whether to drop geo-code and geo-nearest inside stable. Well, if you plan to rebase all current Fedora versions to 2.10 once it's released, that will happen anyway. On the other hand, Debian maintainer seems have only dropped gpssmswatch, and patched other cases: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508597#22 The patches in our BZ for geo-code and geo-nearest should be usable, but as the scripts were dropped upstream, they'll disappear for the user sooner or later, it seems.
Sorry, this dropped off my radar again. ;( - CVE-2008-4959 (bug #470241) - fixed upstream by dropping geo-code - CVE-2008-5380 (bug #475478) - fixed upstream by dropping geo-code and geo-nearest I'm ok with removing all those. - CVE-2008-5703 (bug #481702) - fixed upstream by dropping gpssmswatch and fixing splash.c I have a patch for splash.c, which I will check in here and build. - CVE-2008-5704 (bug #481703) - fixed upstream by fixing unit_test.c This file doesn't seem to be shipped in 2.09 at all. I don't think we are vulnerable to that one. I will commit and do a rawhide build now... let me know if you see any issues. I can push stable updates if everything looks ok in rawhide.
gpsdrive-2.09-7.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
gpsdrive-2.09-7.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.