70825 2004-11-11 11:00 0000 app-arch/gzip: tempfile vulnerabilities 2004-12-29 15:27:59 0000 1 Unclassified Gentoo Security Vulnerabilities unspecified All All RESOLVED FIXED A? [stable] koon P2 normal --- 1 ruth@gentoo.org security@gentoo.org agriffis@gentoo.org ruth@gentoo.org 2004-11-11 11:00:31 0000 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 ruth@gentoo.org 2004-11-11 11:01:40 0000 Created an attachment (id=43732) ...the patch... jaervosz@gentoo.org 2004-11-11 11:37:55 0000 Audit please confirm. solar@gentoo.org 2004-11-11 17:14:38 0000 Patch looks good. Please add security-audit@ to the CC: when your wanting somebody from that team to confirm something in the future. solar@gentoo.org 2004-11-11 17:17:37 0000 Anybody what what might call znew in our build system? (ebuilds, runtime or otherwise) vapier@gentoo.org 2004-11-11 19:57:01 0000 also review Bug 70277 ruth@gentoo.org 2004-11-11 23:07:12 0000 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 jaervosz@gentoo.org 2004-11-11 23:58:56 0000 Thanks solar noted. Is this patch acceptable? If so please provide an updated ebuild. jaervosz@gentoo.org 2004-11-16 23:33:23 0000 solar/agriffis if this patch is acceptable please apply it or advise. solar@gentoo.org 2004-11-17 13:36:14 0000 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) solar@gentoo.org 2004-11-17 14:22:37 0000 No changes to the patch. If changes are desired, then those changes must be attached here. (I'm thinking that you probably want changes) koon@gentoo.org 2004-11-18 02:17:57 0000 Arches, please test znew in gzip-1.3.5-r3 and mark stable. gustavoz@gentoo.org 2004-11-18 03:14:35 0000 sparc stable. tester@gentoo.org 2004-11-18 07:27:38 0000 x86 there lu_zero@gentoo.org 2004-11-18 08:46:08 0000 ppc too hardave@gentoo.org 2004-11-18 09:01:15 0000 Stable on mips. corsair@gentoo.org 2004-11-18 11:35:11 0000 stable on ppc64 sekretarz@gentoo.org 2004-11-18 13:24:14 0000 Stable on amd64 kloeri@gentoo.org 2004-11-18 13:50:04 0000 Stable on alpha. koon@gentoo.org 2004-11-18 14:00:18 0000 Ready for GLSA Maybe upstream/vendor-sec sync would be a good idea ? koon@gentoo.org 2004-11-22 01:47:26 0000 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. koon@gentoo.org 2004-11-23 00:36:47 0000 Florian : could you extend your patch to improve unpredictability in gzexe as well ? koon@gentoo.org 2004-11-23 08:14:51 0000 Downgrading severity jaervosz@gentoo.org 2004-12-08 00:47:14 0000 Solar since Florian is MIA please advise. koon@gentoo.org 2004-12-08 07:15:49 0000 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 ? lewk@gentoo.org 2004-12-08 07:44:12 0000 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 solar@gentoo.org 2004-12-08 08:56:44 0000 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. solar@gentoo.org 2004-12-12 16:30:23 0000 I remain backed up please have 'another dev' review and apply patches. vapier@gentoo.org 2004-12-12 20:33:25 0000 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 vapier@gentoo.org 2004-12-12 20:34:55 0000 ive added 1.3.5-r4 to portage which resolves Bug 70825 and updates the znew patch with the extended mdk version koon@gentoo.org 2004-12-13 01:02:40 0000 Arches, please test and mark 1.3.5-r4 stable Target KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc x86" dragonheart@gentoo.org 2004-12-13 03:19:06 0000 ppc stable as requested. the arch race begins again. gustavoz@gentoo.org 2004-12-13 04:57:42 0000 sparc stable. kingtaco@gentoo.org 2004-12-13 06:52:22 0000 stable on amd64 koon@gentoo.org 2004-12-13 09:22:01 0000 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. vapier@gentoo.org 2004-12-13 15:37:13 0000 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 koon@gentoo.org 2004-12-14 01:21:06 0000 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. koon@gentoo.org 2004-12-14 04:41:11 0000 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). gmsoft@gentoo.org 2004-12-14 06:45:18 0000 Stable on hppa. corsair@gentoo.org 2004-12-14 08:05:41 0000 stable on ppc64 kloeri@gentoo.org 2004-12-14 13:37:41 0000 Stable on alpha. vapier@gentoo.org 2004-12-15 16:58:42 0000 arm/ia64/s390/sh/x86 stable koon@gentoo.org 2004-12-16 01:16:48 0000 Fixed in all supported arches, and closed without GLSA because it's a security improvement more than a vulnerability fix. hardave@gentoo.org 2004-12-29 15:27:59 0000 Stable on mips. 43732 2004-11-11 11:01 0000 ...the patch... znew-secutity.diff text/plain LS0tIC4vem5ldy5pbn4JMjAwNC0xMS0xMSAxOTo0MDozMC4wMDAwMDAwMDAgKzAxMDAKKysrIC4v em5ldy5pbgkyMDA0LTExLTExIDE5OjUxOjIwLjEwMDY1MDM5MiArMDEwMApAQCAtMTQsMTAgKzE0 LDE1IEBACiAjIGJsb2NrIGlzIHRoZSBkaXNrIGJsb2NrIHNpemUgKGJlc3QgZ3Vlc3MsIG5lZWQg bm90IGJlIGV4YWN0KQogCiB3YXJuPSIoZG9lcyBub3QgcHJlc2VydmUgbW9kZXMgYW5kIHRpbWVz dGFtcCkiCi10bXA9L3RtcC96Zm9vLiQkCit0bXA9YHRlbXBmaWxlIC1kIC90bXAgLXAgemZvb2Ag fHwgeworICAgICAgICBlY2hvICdjYW5ub3QgY3JlYXRlIGEgdGVtcG9yYXJ5IGZpbGUnID4mMgor ICAgICAgICBleGl0IDEKK30KIHNldCAtQwogZWNobyBoaSA+ICR0bXAuMSB8fCBleGl0IDEKIGVj aG8gaGkgPiAkdG1wLjIgfHwgZXhpdCAxCit0cmFwICdybSAtZiAkdG1wLjE7IGV4aXQgMicgSFVQ IElOVCBQSVBFIFRFUk0gMAordHJhcCAncm0gLWYgJHRtcC4yOyBleGl0IDInIEhVUCBJTlQgUElQ RSBURVJNIDAKIGlmIHRlc3QgLXogImAoJHtDUE1PRC1jcG1vZH0gJHRtcC4xICR0bXAuMikgMj4m MWAiOyB0aGVuCiAgIGNwbW9kPSR7Q1BNT0QtY3Btb2R9CiAgIHdhcm49IiIK