[DebianGIS-dev] Bug#508595: CVE-2008-5380: allows local users to overwrite arbitrary files via a symlink attack

Hamish hamish_b at yahoo.com
Thu Dec 18 02:42:01 UTC 2008


Tomas Hoger wrote:
> It seems that upstream fix for this issue is far from being
> ideal.
> 
> > TMP=`tempfile -d /tmp -p geo. -s .code`
> 
> [...]
> 
> > so calling this "fixed-upstream" and hoping that tempfile is somewhat
> > portable beyond Debian.
> 
> Any particular reason for using Debian-specific tempfile, instead of
> generally available mktemp?

just pure ignorance of non-Debian things on my part, and cluttered web
search results.

 
> Apart from the portability issues of the fix,

[easily fixed]

> the fix is not address the flaw properly as well.  Even though TMP file
> (never used, IIRC) is created in a secure way, all other temporary files
> are not (STYLE, COORDS, OUTWAY, MAP for geo-code).  So when TMP is
> created, local user can see its name and can create malicious symlinks
> TMP.style, .coords, .way, .gif before script will attempt to use them
> for the first time (or guess or brute-force TMP name in advance).

ok, race condition...


> You either have to create all temporary files using mktemp, or make TMP
> a temporary directory

e.g. as earlier:
tmp="/tmp/geo-code.$$"
(umask 077 && mkdir "$tmp") || {
    echo "Cannot create temporary directory! Exiting." 1>&2
    exit 1
}

> (or dot-directory in user's home dir and you do not have to care about
> creating it securely at all).

but then you need to be more pedantic about cleanup,

 
> There are still few other issues in geo-nearest, like:

ok, well those scripts are now removed in upstream SVN r2204 so it's a
moot point. they were old contrib stuff far outside the purpose of the
main program....
it's safe to remove them in the pre4 packaging.


> See following bugs for the patch that is in preparation for
> Fedora packages:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=470241
>   https://bugzilla.redhat.com/show_bug.cgi?id=475478

thanks for the tips, it is always good to learn how to do these things
more properly. I do wish people would take the time to push these
patches/bug reports upstream instead of 3 teams doing the same work... :)


regards,
Hamish



      






More information about the Pkg-grass-devel mailing list