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 attachment 43732 [details, diff] ...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.
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.
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.
