154310 2006-11-06 22:19 0000 mail-client/mutt <= 1.5.12 temp file issue (CVE-2006-529[78]) 2007-09-01 21:33:59 0000 1 Unclassified Gentoo Security Vulnerabilities unspecified All Linux RESOLVED FIXED http://marc.theaimsgroup.com/?l=mutt-dev&m=115999486426292&w=2 B? [noglsa] vorlon P2 normal --- 178003 1 jaervosz@gentoo.org security@gentoo.org agriffis@gentoo.org ferdy@gentoo.org net-mail@gentoo.org jaervosz@gentoo.org 2006-11-06 22:19:38 0000 It would seem that Mutt's temp file creation mechanisms all suffer from a potentially exploitable race condition. Actually there are two: one in functions that call safe_open(), which only affects users creating temp files on NFS file systems (due to the O_EXCL problem), and one in functions that make use of safe_fopen(), because the resulting file is not adequately checked to determine if other users can modify it before it is written to. On Wed, Oct 04, 2006 at 11:19:26AM -0400, Kyle Wheeler wrote: > char tmpfile[POSIX_PATH_MAX] = "/tmp/muttXXXXXX"; > char tmpfile2[POSIX_PATH_MAX]; > char *extension = "foo"; > // mkstemp should come first > fd = mkstemp(tmpfile); > sprintf(tmpfile2, "%s.%s", tmpfile, extension); > rename(tmpfile, tmpfile2); The trouble with this is that while tmpfile is "guaranteed" unique, tmpfile.foo may well not be. :( Granted, it would be hard to exploit, but theoretically not impossible. You still need to be careful to open the file with O_CREAT|O_EXCL and expect that it could fail (which I believe mutt does, though I didn't verify every possible case). Unfortunately even that isn't really enough given that lots of people set TMPDIR to something in their home directory, and have home directories on NFS. Opening a file this way (with O_EXCL) on NFS is broken (and thus so are any implementations of mkstemp() family functions that rely on it). You can do the link(2) trick too, but AFAICT there's no way to guarantee that the file you're creating is unique on NFS without encountering a race condition. This is a weakness in the NFS protocol IIRC, not in the implementation of mkstemp(). [This may not be the case with NFSv4, I am uncertain.] The man page for open(2) mentions this. That's problem #1. The scheme that mutt currently uses for most of its temp files (_mutt_mktemp()/safe_open()) involves using the host name, UID, pid, and an internal counter maintained by mutt. The trouble is, it's fairly likely that a user will go through the exact same steps when they boot their workstation (i.e. when starting mutt immediately after booting the system), so for any particular user the likelihood is surprisingly high that all of these pieces (including the PID) except for the counter will frequently be the same for any given user, thus very guessable. Only the counter will change, and it's always initialized to zero, so that also is not hard to guess. At a glance, I don't see mutt doing anything to check to see if for such files, the user is the only one who can read and/or write to the file. Certainly functions that call safe_open() use O_EXCL, but due to the problems with that working on NFS, that may not be enough. Also NFS or no NFS, with regard to mutt_adv_mktemp() for attachments, calls to safe_fopen() generally use "w+" which means the file will be truncated if it exists, but that doesn't do anything to ensure that the file so created couldn't be moved aside and replaced with a malicious file should the directory be writable by someone else; nor does it do anything to prevent the race where someone else creates the file in between the calls to mktemp() and safe_fopen(). In the latter case, the file will be truncated, but the file is still writable by the owner and can potentially be modified in a malicious way before mutt runs the MIME type's helper program on it. Is this exploitable? It would seem so, though executing such a maneuver is probably exceedingly difficult. An attacker would need to be able to guess the temp file name in advance, know what kind of data was going into it, and be able to craft malicious data which would exploit some problem in the program it was going to be fed into... Still, mutt really ought to be creating a unique directory in which to create its temp files, and before doing so it should make sure the permissions on that directory are 700 and owned by the user. It should also make sure that the parent directory either allows access only to the user, or that it has the sticky bit set. There's still a possible race condition involving creating a unique directory name, but fortunately mkdir(2) always fails if the directory already exists, which largely solves the problem. Further, checking the permissions and ownership on the directory before creating the temp file should eliminate any remaining doubt. On Wed, Oct 04, 2006 at 11:36:43AM -0400, Kyle Wheeler wrote: > On the other hand, mkstemps() would solve the problem, at least for > the OS's that support it, i.e. all modern Unixes (it works on Tru64 > Unix, Solaris, FreeBSD, OpenBSD, NetBSD, MacOS X, OpenSolaris, > Solaris, and Linux). $ uname -smr Linux 2.4.20-20.9 i686 $ man mkstemps No manual entry for mkstemps $ gcc mkstemps.c /home/ddm/tmp/ccvsG8nh.o(.text+0x17): In function `main': : undefined reference to `mkstemps' collect2: ld returned 1 exit status You were saying? This function is not sufficiently portable to rely upon its presence. At best you'd need to provide an alternate implementation, in which case there's no obvious benefit to using it... mutt_adv_mktemp() basically does the same thing already. Note that mkstemps also relies on O_EXCL so it also suffers from a race condition on NFS. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. jaervosz@gentoo.org 2006-11-06 22:21:16 0000 OWL has a large patch reworking tmp file handling in mutt: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/mutt/mutt-1.4.2.1-owl-tmp.diff vorlon@gentoo.org 2006-11-07 03:12:46 0000 opening the bug since the mail can be found at <http://marc.theaimsgroup.com/?l=mutt-dev&m=115999486426292&w=2> <http://secunia.com/advisories/22613/> vorlon@gentoo.org 2006-11-09 06:10:32 0000 CC'ing maintainers Ubuntu announcement can be found at http://www.ubuntu.com/usn/usn-373-1 so there should be patches available too jaervosz@gentoo.org 2006-11-20 22:41:21 0000 Pulling in herd for advise/bumping. ferdy@gentoo.org 2006-11-20 23:49:09 0000 Ok, I've digged in the recent mutt commits and the only reference to temp files / security is the attached one. I'll apply it later today if any of you can ACK the patch. - ferdy ferdy@gentoo.org 2006-11-20 23:50:13 0000 Created an attachment (id=102446) paranoid-temp-file.patch Proposed patch from upstream. ferdy@gentoo.org 2006-11-22 00:17:58 0000 That patch is being applied in mail-client/mutt-1.5.13-r2. If it is not enough to fix this bug please state so and I'll try to get in touch with upstream. - ferdy jaervosz@gentoo.org 2006-11-22 00:29:03 0000 Vorlon is this patch enough? vorlon@gentoo.org 2006-11-27 06:55:39 0000 could someone pls verify the patch? (tavis/...?) ferdy@gentoo.org 2007-03-20 20:04:33 0000 mutt-1.5.14 is in the tree now (with this patch included too). I haven't seen more patches related to this bug. Is this bug still considered valid? Do I have to do anything else? - ferdy jaervosz@gentoo.org 2007-03-25 11:00:32 0000 Tavis please advise. jaervosz@gentoo.org 2007-04-18 05:55:09 0000 Tavis please advise. jaervosz@gentoo.org 2007-05-02 12:10:14 0000 Tavis please advise. jaervosz@gentoo.org 2007-05-20 07:31:42 0000 Tavis please advise. falco@gentoo.org 2007-06-09 21:25:47 0000 > char tmpfile[POSIX_PATH_MAX] = "/tmp/muttXXXXXX"; > char tmpfile2[POSIX_PATH_MAX]; > char *extension = "foo"; > // mkstemp should come first > fd = mkstemp(tmpfile); > sprintf(tmpfile2, "%s.%s", tmpfile, extension); > rename(tmpfile, tmpfile2); rename() is not vulnerable to a symlink attack, unlike open(). The race conditions explained in the mail needs other successful attacks, or administrator misconfigurations. Non-issue for me. For the O_EXCL which doesn't work on NFS, that may be a weakness, but this would affect all other apps using O_EXCL. It's not mutt specific and it can't simply be solved. Furthermore, /tmp on a NFS... sounds... eccentric. (why not, but in that case it is also a misconfiguration since that will affect many applications). Non-issue for me. I'm an addicted mutt user and despite of that, I think we can close this bug as Invalid. falco@gentoo.org 2007-06-09 21:50:09 0000 mmm after a deeper look to the mailing list, the syscall to rename() should be checked (return value equals 0 or -1). Indeed, if the files are: -rw------- 1 falco falco 0 Jun 9 23:46 muttjlNOGW -rw-r--r-- 1 foo foo 5 Jun 9 23:46 muttjlNOGW.foo Then the rename() call fails, mutt continues, and read/write from/to the crafted muttjlNOGW.foo file. Yes, that's a bug (another user could view the mails). Not a security issue (DoS, code exec, or so). py@gentoo.org 2007-07-21 10:15:24 0000 according to the CVE refs, this affects versions 1.5.12 and earlier, and we have version .13 stable and versions .14 and .15 unstable in the tree, so what should we do here? Ferdy/Aggrifis/net-mail, please advise. ferdy@gentoo.org 2007-08-08 09:47:44 0000 I just commited mutt-1.5.16. There is no point in stabling .15 so I'd go for .16 myself once arch people deem it appropiate. We can start removing vulnerable unused versions though. - ferdy jaervosz@gentoo.org 2007-08-14 10:32:20 0000 Handling stable marking on bug #178003 py@gentoo.org 2007-09-01 21:33:59 0000 finally closing without GLSA wrt the discussion on bug 178003, feel free to reopen if you disagree. 102446 2006-11-20 23:50 0000 paranoid-temp-file.patch paranoid-temp-file.patch text/plain Y29tbWl0IGY4YzQyYzYyODZmMzA3N2ZjODc2MmJhMmM4MzIzMDI2YjczNmEzZTgKQXV0aG9yOiBy b2Vzc2xlciA8cm9lc3NsZXI+CkRhdGU6ICAgTW9uIE9jdCA5IDEzOjM5OjM4IDIwMDYgKzAwMDAK CiAgICBGcm9tOiBUaG9tYXMgUm9lc3NsZXIgPHJvZXNzbGVyQGRvZXMtbm90LWV4aXN0Lm9yZz4K ICAgIAogICAgRXZlbiBtb3JlIHBhcmFub2lkIHRlbXBvcmFyeSBmaWxlIGNyZWF0aW9uLgoKZGlm ZiAtLWdpdCBhL2xpYi5jIGIvbGliLmMKaW5kZXggYWFjMDc0Mi4uZDY3MmE4YSAxMDA2NDQKLS0t IGEvbGliLmMKKysrIGIvbGliLmMKQEAgLTQ4MSwxNCArNDgxLDg1IEBAIGludCBzYWZlX3JlbmFt ZSAoY29uc3QgY2hhciAqc3JjLCBjb25zdAogICByZXR1cm4gMDsKIH0KIAorLyogQ3JlYXRlIGEg dGVtcG9yYXJ5IGRpcmVjdG9yeSBuZXh0IHRvIGEgZmlsZSBuYW1lICovCisKK2ludCBtdXR0X21r d3JhcGRpciAoY29uc3QgY2hhciAqcGF0aCwgY2hhciAqbmV3ZmlsZSwgc2l6ZV90IG5mbGVuLCAK KwkJICAgIGNoYXIgKm5ld2Rpciwgc2l6ZV90IG5kbGVuKQoreworICBjb25zdCBjaGFyICpiYXNl bmFtZTsKKyAgY2hhciBwYXJlbnRbX1BPU0lYX1BBVEhfTUFYXTsKKyAgY2hhciAqcDsKKyAgaW50 IHJ2OworCisgIHN0cmZjcHkgKHBhcmVudCwgTk9OVUxMIChwYXRoKSwgc2l6ZW9mIChwYXJlbnQp KTsKKyAgCisgIGlmICgocCA9IHN0cnJjaHIgKHBhcmVudCwgJy8nKSkpCisgIHsKKyAgICAqcCA9 ICdcMCc7CisgICAgYmFzZW5hbWUgPSBwICsgMTsKKyAgfQorICBlbHNlCisgIHsKKyAgICBzdHJm Y3B5IChwYXJlbnQsICIuIiwgc2l6ZW9mIChwYXJlbnQpKTsKKyAgICBiYXNlbmFtZSA9IHBhdGg7 CisgIH0KKworICBkbyAKKyAgeworICAgIHNucHJpbnRmIChuZXdkaXIsIG5kbGVuLCAiJXMvJXMi LCBwYXJlbnQsICIubXV0dFhYWFhYWCIpOworICAgIG1rdGVtcCAobmV3ZGlyKTsKKyAgfSAKKyAg d2hpbGUgKChydiA9IG1rZGlyIChuZXdkaXIsIDA3MDApKSA9PSAtMSAmJiBlcnJubyA9PSBFRVhJ U1QpOworICAKKyAgaWYgKHJ2ID09IC0xKQorICAgIHJldHVybiAtMTsKKyAgCisgIHNucHJpbnRm IChuZXdmaWxlLCBuZmxlbiwgIiVzLyVzIiwgbmV3ZGlyLCBOT05VTEwoYmFzZW5hbWUpKTsKKyAg cmV0dXJuIDA7ICAKK30KKworaW50IG11dHRfcHV0X2ZpbGVfaW5fcGxhY2UgKGNvbnN0IGNoYXIg KnBhdGgsIGNvbnN0IGNoYXIgKnNhZmVfZmlsZSwgY29uc3QgY2hhciAqc2FmZV9kaXIpCit7Cisg IGludCBydjsKKyAgCisgIHJ2ID0gc2FmZV9yZW5hbWUgKHNhZmVfZmlsZSwgcGF0aCk7CisgIHVu bGluayAoc2FmZV9maWxlKTsKKyAgcm1kaXIgKHNhZmVfZGlyKTsKKyAgcmV0dXJuIHJ2OworfQor CiBpbnQgc2FmZV9vcGVuIChjb25zdCBjaGFyICpwYXRoLCBpbnQgZmxhZ3MpCiB7CiAgIHN0cnVj dCBzdGF0IG9zYiwgbnNiOwogICBpbnQgZmQ7CiAKLSAgaWYgKChmZCA9IG9wZW4gKHBhdGgsIGZs YWdzLCAwNjAwKSkgPCAwKQotICAgIHJldHVybiBmZDsKKyAgaWYgKGZsYWdzICYgT19FWENMKSAK KyAgeworICAgIGNoYXIgc2FmZV9maWxlW19QT1NJWF9QQVRIX01BWF07CisgICAgY2hhciBzYWZl X2RpcltfUE9TSVhfUEFUSF9NQVhdOwogCisgICAgaWYgKG11dHRfbWt3cmFwZGlyIChwYXRoLCBz YWZlX2ZpbGUsIHNpemVvZiAoc2FmZV9maWxlKSwKKwkJCXNhZmVfZGlyLCBzaXplb2YgKHNhZmVf ZGlyKSkgPT0gLTEpCisgICAgICByZXR1cm4gLTE7CisgICAgCisgICAgaWYgKChmZCA9IG9wZW4g KHNhZmVfZmlsZSwgZmxhZ3MsIDA2MDApKSA8IDApCisgICAgeworICAgICAgcm1kaXIgKHNhZmVf ZGlyKTsKKyAgICAgIHJldHVybiBmZDsKKyAgICB9CisgICAgCisgICAgaWYgKG11dHRfcHV0X2Zp bGVfaW5fcGxhY2UgKHBhdGgsIHNhZmVfZmlsZSwgc2FmZV9kaXIpID09IC0xKQorICAgIHsKKyAg ICAgIGNsb3NlIChmZCk7CisgICAgICByZXR1cm4gLTE7CisgICAgfQorICB9CisgIGVsc2UKKyAg eworICAgIGlmICgoZmQgPSBvcGVuIChwYXRoLCBmbGFncywgMDYwMCkpIDwgMCkKKyAgICAgIHJl dHVybiBmZDsKKyAgfQorICAgIAogICAvKiBtYWtlIHN1cmUgdGhlIGZpbGUgaXMgbm90IHN5bWxp bmsgKi8KICAgaWYgKGxzdGF0IChwYXRoLCAmb3NiKSA8IDAgfHwgZnN0YXQgKGZkLCAmbnNiKSA8 IDAgfHwKICAgICAgIGNvbXBhcmVfc3RhdCgmb3NiLCAmbnNiKSA9PSAtMSkK