Bug 470241 - (CVE-2008-4959) CVE-2008-4959 gpsdrive: geo-code insecure temporary file use
CVE-2008-4959 gpsdrive: geo-code insecure temporary file use
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
http://nvd.nist.gov/nvd.cfm?cvename=C...
impact=?,cwe=CWE-377[auto]
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-06 08:12 EST by Tomas Hoger
Modified: 2016-03-04 06:42 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-29 05:20:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch used by Debian (1.87 KB, patch)
2008-11-06 08:22 EST, Tomas Hoger
no flags Details | Diff
patch for issue (1.04 KB, patch)
2008-12-14 20:40 EST, Kevin Fenzi
no flags Details | Diff
patch for issue. (1.10 KB, patch)
2008-12-16 01:23 EST, Kevin Fenzi
no flags Details | Diff

  None (edit)
Description Tomas Hoger 2008-11-06 08:12:56 EST
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
Comment 1 Tomas Hoger 2008-11-06 08:22:48 EST
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.)
Comment 2 Kevin Fenzi 2008-11-06 18:30:57 EST
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.
Comment 3 Kevin Fenzi 2008-11-10 17:35:29 EST
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?
Comment 4 Tomas Hoger 2008-11-11 02:43:44 EST
(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.
Comment 5 Kevin Fenzi 2008-12-14 20:40:00 EST
Created attachment 326896 [details]
patch for issue

Here's a proposed patch. 
Sorry for the lengthly delay here... this fell off my radar. ;(
Comment 6 Tomas Hoger 2008-12-15 05:24:20 EST
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.
Comment 7 Kevin Fenzi 2008-12-16 01:23:43 EST
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?
Comment 8 Tomas Hoger 2008-12-16 08:45:59 EST
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.
Comment 9 Tomas Hoger 2008-12-19 14:01:11 EST
Affected scripts were dropped upstream:
http://gpsdrive.svn.sourceforge.net/viewvc/gpsdrive?view=rev&revision=2204
Comment 10 Kevin Fenzi 2008-12-22 19:01:20 EST
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?
Comment 11 Tomas Hoger 2009-01-27 03:57:08 EST
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.
Comment 12 Kevin Fenzi 2009-02-02 22:49:11 EST
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.
Comment 13 Fedora Update System 2009-02-04 21:10:11 EST
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.
Comment 14 Fedora Update System 2009-02-04 21:22:33 EST
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.

Note You need to log in before you can comment on or make changes to this bug.