Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

hi,
i have found a tempfile vulnerability in the utility znew, part of app-arch/gzip

affected code in znew.in:

-- snip --

warn="(does not preserve modes and timestamp)"
tmp=/tmp/zfoo.$$
set -C
echo hi > $tmp.1 || exit 1
echo hi > $tmp.2 || exit 1
if test -z "`(${CPMOD-cpmod} $tmp.1 $tmp.2) 2>&1`"; then
  cpmod=${CPMOD-cpmod}
  warn=""
fi

-- snap --

as you can see, the temporary file is created highly insecure. (derived from the pid!!!)
therefore, an attacker can create a link for example to shadow or passwd and overwrite that file.

attached is a diff, that resolves this issue

best regards
florian

Created an attachment (id=43732) [details]
...the patch...

Audit please confirm.

Patch looks good. Please add security-audit@ to the CC: when your wanting
somebody from that team to confirm something in the future.

Anybody what what might call znew in our build system? (ebuilds, runtime or
otherwise)

also review Bug 70277

hi, i have revieved the Bug 70277:

i guess, the problem is here:
line 37:
tmp=`tempfile -d /tmp -p gz` || {
...
this actually _creates_ a temporary file...
and this behaviour of tempfile is the reason, why
line 53:
gzip -cdfq "$2" > $tmp || exit
(correctly) refuses to extract to an existing file...

solution:

one could unlink the tempfile after creating it with tempfile
note, that this solution would introduce (theoretically) a race condition...
(an attacker knows the tempfilename after unlinking and _before_ actually writing to that file)
as gzip refuses to extract, if the file already exists, i guess this would be a 
good solution anyways...

further comments?

best regards
florian

Thanks solar noted.

Is this patch acceptable? If so please provide an updated ebuild.

solar/agriffis if this patch is acceptable please apply it or advise.

Old:
gzip-1.3.5-r2 
KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc x86"

New:
gzip-1.3.5-r3 
KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86"


Changes include only addition of files/gzip-1.3.5-znew-tempfile.patch from this bug. (Not well tested)

No changes to the patch. If changes are desired, then those changes must be
attached here. (I'm thinking that you probably want changes)

Arches, please test znew in gzip-1.3.5-r3 and mark stable.

sparc stable.

x86 there

ppc too

Stable on mips.

stable on ppc64

Stable on amd64

Stable on alpha.

Ready for GLSA
Maybe upstream/vendor-sec sync would be a good idea ?

gzexe has the same predictable tmpfile "vulnerability".

--------------------------------
echo hi > zfoo1$$ || exit 1
echo hi > zfoo2$$ || exit 1
if test -z "`(${CPMOD-cpmod} zfoo1$$ zfoo2$$) 2>&1`"; then
  cpmod=${CPMOD-cpmod}
fi
rm -f zfoo[12]$$
--------------------------------

This is CAN-2004-0970 (both znew and gzexe), but our patch can be considered insufficient as it relies on $$ which is quite predictable on most machines. Strange thing being it was considered sufficient for DSA-588-1...

Note: Debian stable and testing are vulnerable to the znew $$ one.
Debian testing is vulnerable to the gzexe $$ one, but Debian stable has a different approach and doesn't seem vulnerable to that one.

Florian : could you extend your patch to improve unpredictability in gzexe as
well ?

Downgrading severity

Solar since Florian is MIA please advise.

Mandrake just has a tmpfile gzip advisory out :
http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:142

Don't know if they fix as much as we do... rip the SRPM to find out ?

Mandrake patches:

http://dev.gentoo.org/~lewk/gzip/gzip-1.2.4-gzexe.patch.bz2
http://dev.gentoo.org/~lewk/gzip/gzip-1.2.4a-mktemp.patch.bz2
http://dev.gentoo.org/~lewk/gzip/gzip-1.2.4a-zdiff-CAN-2004-0970.patch
http://dev.gentoo.org/~lewk/gzip/gzip-1.2.4a-znew.patch.bz2

Sorry I'm a little backed up right now. Will review this bug later. 
Side note anything that requires my direct attention should be mailed to me directly for the next few weeks.

I remain backed up please have 'another dev' review and apply patches.

gzip-1.2.4-gzexe.patch
 - not applicable to 1.3.5 afaict
gzip-1.2.4a-znew.patch
 - updated our local patch to use this extended version
gzip-1.2.4a-zdiff-CAN-2004-0970.patch
 - this is our gzip-1.3.5-zdiff-tempfile.patch
gzip-1.2.4a-mktemp.patch
 - our deb patch already has this in it

ive added 1.3.5-r4 to portage which resolves Bug 70825 and updates the znew
patch with the extended mdk version

Arches, please test and mark 1.3.5-r4 stable
Target KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc x86"

ppc stable as requested. the arch race begins again.

sparc stable.

stable on amd64

Hmm the vulnerability in gzexe is still there in 1.3.5-r4 :

------------ snip -----------
echo hi > zfoo1$$ || exit 1
echo hi > zfoo2$$ || exit 1
------------ snip -----------

uncalling arches, the time to produce a updated patch.

i'm pretty sure it's not

look up a few lines in gzexe.in:
set -C

that means bash wont clobber files with redirects:
$ [[ -e clobber ]] && echo f
$ set -C
$ echo f > clobber
$ echo f > clobber
bash: clobber: cannot overwrite existing file

Hmm you're right. Apparently the vulnerability this bug was originally about is
nullified by the set -C thing. Thanks for pointing that out, back to the stable
game, sorry for the interference.

Given that the patches present were already sufficiently good, this will be
closed without GLSA when all supported arches will have marked stable.

Florian: if you disagree, feel free to reopen this bug... I'm getting tired by
those recurring gzip script tmpfile bugs (they just won't stay dead).

Stable on hppa.

stable on ppc64

Stable on alpha.

arm/ia64/s390/sh/x86 stable

Fixed in all supported arches, and closed without GLSA because it's a security
improvement more than a vulnerability fix.

Stable on mips.