86257 2005-03-22 06:31 0000 sys-fs/e2fsprogs: BLKID_FILE should not be honored in SUID 2005-06-11 01:18:18 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All All RESOLVED FIXED http://sourceforge.net/projects/e2fsprogs ~1 [noglsa] koon P2 trivial --- 1 koon@gentoo.org security@gentoo.org koon@gentoo.org 2005-03-22 06:31:40 0000 e2fsprogs 1.37 contains the following fix : * cache.c (blkid_get_cache): Ignore the BLKID_FILE environment variable if blkid_get_cache() is called from a setuid program. The official patch is here : ======================================================= diff -Nru a/lib/blkid/cache.c b/lib/blkid/cache.c --- a/lib/blkid/cache.c 2005-03-22 07:01:25 -05:00 +++ b/lib/blkid/cache.c 2005-03-22 07:01:25 -05:00 @@ -41,7 +41,7 @@ if (filename && !strlen(filename)) filename = 0; - if (!filename) + if (!filename && (getuid() == geteuid())) filename = getenv("BLKID_FILE"); if (!filename) filename = BLKID_CACHE_FILE; ====================================================== Solar Designer (Openwall) suggested the following Linux-only (better) alternative : ====================================================== filename = 0; if (!filename) - filename = getenv("BLKID_FILE"); + filename = __secure_getenv("BLKID_FILE"); if (!filename) filename = BLKID_CACHE_FILE; ====================================================== base-system, please advise. solar@gentoo.org 2005-03-22 11:46:52 0000 __secure_getenv() exists only in glibc. It's not portable and we have had problems with patches of his in the past in which __secure_env() crept in. solar@gentoo.org 2005-03-22 11:55:15 0000 How about this? --- lib/blkid/cache.c.orig 2005-03-22 14:48:19.000000000 -0500 +++ lib/blkid/cache.c 2005-03-22 14:53:08.000000000 -0500 @@ -41,8 +41,13 @@ int blkid_get_cache(blkid_cache *ret_cac if (filename && !strlen(filename)) filename = 0; - if (!filename) + + if (!filename && (getuid() == geteuid())) +#ifdef __UCLIBC__ filename = getenv("BLKID_FILE"); +#else + filename = __secure_getenv("BLKID_FILE"); +#endif if (!filename) filename = BLKID_CACHE_FILE; cache->bic_filename = blkid_strdup(filename); solar@gentoo.org 2005-03-22 12:26:05 0000 Created an attachment (id=54173) e2fsprogs-1.36-r3.ebuild.diff solar@gentoo.org 2005-03-22 12:26:58 0000 Created an attachment (id=54174) e2fsprogs-1.36-blkid-cache.patch robbat2@gentoo.org 2005-03-22 13:38:50 0000 I'd think it would be better to do it the other way around, eg. explictly check for GLIBC before using __secure_getenv. This ensures it can compile on any other libc as opposed to just uclibc. koon@gentoo.org 2005-03-22 13:55:48 0000 We should wait for upstream a little before they chose a final patch solar@gentoo.org 2005-03-22 14:12:33 0000 agriffis put the following proposed solution for this. tested on uClibc and it compiles fine after running autoconf. http://dev.gentoo.org/~agriffis/misc/e2fsprogs-1.36-blkid-cache.patch I mailed <tytso@mit.edu> about it, awaiting reply. vapier@gentoo.org 2005-03-22 15:46:07 0000 1.37 is now in portage w/out any patch here ... i'd prefer upstream handle this which is what Nedd is pursuing is e2fsprogs-1.35 affected or is it just 1.36 ? if it's just 1.36, then ia64 is the only one who had that version stable [it was marked last nite ...] solar@gentoo.org 2005-03-22 16:37:56 0000 I'm pretty sure it's 1.36 only. koon@gentoo.org 2005-03-23 00:41:20 0000 I know upstream was considering pushing some autoconf stuff to enable/disable use of __secure_getenv. Maybe better to wait for their final choice. solar@gentoo.org 2005-03-23 06:40:07 0000 Anybody know the attack vector here? Like nothing in e2fsprogs is suid afaik. robbat2@gentoo.org 2005-03-23 07:04:56 0000 solar: re: attack vector I think /bin/mount might be an attack vector. it's suid, and uses the function in question (blkid_get_cache). it's got the blkid stuff so you can do 'mount LABEL=foo /bar'. koon@gentoo.org 2005-03-30 07:15:42 0000 Keeping the bug open until upstream final resolution, but won't generate a GLSA as affected versions are unsupported. koon@gentoo.org 2005-04-21 01:17:34 0000 Contacted upstream to see what they plan to do exactly. koon@gentoo.org 2005-05-15 08:13:35 0000 A TEST version 1.38-WIP-0509 has been released... No answer from upstream btw. koon@gentoo.org 2005-06-10 06:54:46 0000 Given that I had no answer from upstream on this, I tend to consider 1.37 is probably the final upstream fix for that. So should we consider this one fixed ? vapier@gentoo.org 2005-06-10 18:18:34 0000 works for me ia64 is now stable in 1.37-r1 since ia64 is the only arch that had 1.36 stable koon@gentoo.org 2005-06-11 01:18:18 0000 Closing as SOMEWHATFIXED. Please reopen if you have a better idea. 54173 2005-03-22 12:26 0000 e2fsprogs-1.36-r3.ebuild.diff e2fsprogs-1.36-r3.ebuild.diff text/plain LS0tIGUyZnNwcm9ncy0xLjM2LXIyLmVidWlsZAkyMDA1LTAzLTIyIDE0OjQxOjU1LjAwMDAwMDAw MCAtMDUwMAorKysgZTJmc3Byb2dzLTEuMzYtcjMuZWJ1aWxkCTIwMDUtMDMtMjIgMTQ6NTg6MjAu MDAwMDAwMDAwIC0wNTAwCkBAIC0zMCw2ICszMCw5IEBACiAJIyBDbGVhbiB1cCBtYWtlZmlsZSB0 byBzdWNrIGxlc3MKIAllcGF0Y2ggIiR7RklMRVNESVJ9Ii8ke1B9LW1ha2VmaWxlLnBhdGNoCiAK KwkjODYyNTcgIEJMS0lEX0ZJTEUgc2hvdWxkIG5vdCBiZSBob25vcmVkIGluIFNVSUQuCisJZXBh dGNoICR7RklMRVNESVJ9LyR7UH0tYmxraWQtY2FjaGUucGF0Y2gKKwogCSMga2VybmVsIGhlYWRl cnMgdXNlIHRoZSBzYW1lIGRlZmluZXMgYXMgZTJmc3Byb2dzIGFuZCBjYW4gY2F1c2UgaXNzdWVz ICM0ODgyOQogCXNlZCAtaSBcCiAJCS1lICdzOkNPTkZJR19KQkRfREVCVUc6X19DT05GSUdfSkJE X0RFQlVHX19FMkZTOmcnIFwK 54174 2005-03-22 12:26 0000 e2fsprogs-1.36-blkid-cache.patch e2fsprogs-1.36-blkid-cache.patch text/plain LS0tIGxpYi9ibGtpZC9jYWNoZS5jLm9yaWcJMjAwNS0wMy0yMiAxNDo0ODoxOS4wMDAwMDAwMDAg LTA1MDAKKysrIGxpYi9ibGtpZC9jYWNoZS5jCTIwMDUtMDMtMjIgMTQ6NTM6MDguMDAwMDAwMDAw IC0wNTAwCkBAIC00MSw4ICs0MSwxMyBAQCBpbnQgYmxraWRfZ2V0X2NhY2hlKGJsa2lkX2NhY2hl ICpyZXRfY2FjCiAKIAlpZiAoZmlsZW5hbWUgJiYgIXN0cmxlbihmaWxlbmFtZSkpCiAJCWZpbGVu YW1lID0gMDsKLQlpZiAoIWZpbGVuYW1lKQorCisJaWYgKCFmaWxlbmFtZSAmJiAoZ2V0dWlkKCkg PT0gZ2V0ZXVpZCgpKSkKKyNpZmRlZiBfX1VDTElCQ19fCiAJCWZpbGVuYW1lID0gZ2V0ZW52KCJC TEtJRF9GSUxFIik7CisjZWxzZQorCQlmaWxlbmFtZSA9IF9fc2VjdXJlX2dldGVudigiQkxLSURf RklMRSIpOworI2VuZGlmCiAJaWYgKCFmaWxlbmFtZSkKIAkJZmlsZW5hbWUgPSBCTEtJRF9DQUNI RV9GSUxFOwogCWNhY2hlLT5iaWNfZmlsZW5hbWUgPSBibGtpZF9zdHJkdXAoZmlsZW5hbWUpOwo=