I got root on my sys-kernel/gentoo-sources-2.6.24 with this exploit: % ./a.out ----------------------------------- Linux vmsplice Local Root Exploit By qaaz ----------------------------------- [+] mmap: 0x0 .. 0x1000 [+] page: 0x0 [+] page: 0x20 [+] mmap: 0x4000 .. 0x5000 [+] page: 0x4000 [+] page: 0x4020 [+] mmap: 0x1000 .. 0x2000 [+] page: 0x1000 [+] mmap: 0xb7db8000 .. 0xb7dea000 [+] root # whoami root Reproducible: Always Steps to Reproduce: 1. Compile exploit using gcc 2. Execute it 3. Got root... Actual Results: Privilege escalation
Created attachment 143059 [details] Linux vmsplice Local Root Exploit
Yeah, fixed with http://tinyurl.com/38me8k
Erm... or not... this isn't properly fixed: $ ./a.out ----------------------------------- Linux vmsplice Local Root Exploit By qaaz ----------------------------------- [+] mmap: 0x0 .. 0x1000 [+] page: 0x0 [+] page: 0x20 [+] mmap: 0x4000 .. 0x5000 [+] page: 0x4000 [+] page: 0x4020 [+] mmap: 0x1000 .. 0x2000 [+] page: 0x1000 [+] mmap: 0xb7dfe000 .. 0xb7e30000 Segmentation fault $ ./a.out ----------------------------------- Linux vmsplice Local Root Exploit By qaaz ----------------------------------- [+] mmap: 0x0 .. 0x1000 [+] page: 0x0 [+] page: 0x20 [+] mmap: 0x4000 .. 0x5000 [+] page: 0x4000 [+] page: 0x4020 [+] mmap: 0x1000 .. 0x2000 [+] page: 0x1000 [+] mmap: 0xb7e1e000 .. 0xb7e50000 [-] wtf $ ./a.out ----------------------------------- Linux vmsplice Local Root Exploit By qaaz ----------------------------------- [+] mmap: 0x0 .. 0x1000 [+] page: 0x0 [+] page: 0x20 [+] mmap: 0x4000 .. 0x5000 [+] page: 0x4000 [+] page: 0x4020 [+] mmap: 0x1000 .. 0x2000 [+] page: 0x1000 [+] mmap: 0xb7dd7000 .. 0xb7e09000 [+] root # whoami root
*** Bug 209530 has been marked as a duplicate of this bug. ***
*** Bug 209533 has been marked as a duplicate of this bug. ***
This should fix the issue: From: Bastian Blank <bastian@waldi.eu.org> The commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user pointer access verification") added access_ok() to copy_from_user_mmap_sem() which only ensures we can copy the struct iovecs from userspace to the kernel but we also must check whether we can access the actual memory region pointed to by the struct iovec to close the local root exploit. Cc: <stable@kernel.org> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> --- Bastian, can I have your Signed-off-by for this, please? Oliver, Niki, can you please confirm this closes the hole? fs/splice.c | 3 +++ 1 file changed, 3 insertions(+) Index: linux-2.6/fs/splice.c =================================================================== --- linux-2.6.orig/fs/splice.c +++ linux-2.6/fs/splice.c @@ -1237,6 +1237,9 @@ static int get_iovec_page_array(const st if (unlikely(!base)) break; + if (unlikely(!access_ok(VERIFY_READ, base, len))) + break; + /* * Get this base offset and number of pages, then map * in the user pages. --
*** Bug 209602 has been marked as a duplicate of this bug. ***
(In reply to comment #6) Yeah this looks finally like a working patch...
Created attachment 143165 [details, diff] splice.patch The patch from comment #6 works here on 2.6.22. I had to modify the patch offset slightly, so I'm posting the resulting diff here for the benefit of others.
If I didn't mis-interpret dsd's blog post [1] this should be fixed in gentoo-sources-2.6.23-r8 or gentoo-sources-2.6.24-r2, with the first one having been stabled on x86 and am64 already. Vanilla linux-2.6.23.16 and 2.6.24.2 (containing the fix) have been released as well. (Posting it here as well to keep this bug up-to-date) [1] http://www.reactivated.net/weblog/archives/2008/02/critical-linux-kernel-vmsplice-security-issues/
There is also a different patch around: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464945#54 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=54;filename=patch;att=1;bug=464945
there were various patches thrown up, some did not fix the issue properly, some opened other holes. we took the ones that went upstream
sys-kernel/tuxonice-sources 2.6.23-r10 (genpatches 9) and 2.6.24-r1 (genpatches 3) ready, both should go stable same time as gentoo-sources.
(In reply to comment #0) > I got root on my sys-kernel/gentoo-sources-2.6.24 with this exploit: I tested this on Gentoo Hardened Sources 2.6.18 and it worked as well.. I tried to fix it by uprading to 2.6.23 and applying the patches provided by the linux kernel git repo but for some reason the exploit still works.. when will this be fixed in hardened-sources? Regards, Chris
In response to Comment 14 - I would invite you to have a look at bug 207393 where the matter of updating and committing a new version of hardened-sources is being discussed.
Patch from gentoo-sources-2.6.24-r2 (1400_vmsplice-user-pointer.patch) also applies to xen-sources-2.6.20-r6 and fixed the security issue for me. It would be great, if someone could supply an updated xen-sources package
(In reply to comment #13) > sys-kernel/tuxonice-sources 2.6.23-r10 (genpatches 9) and 2.6.24-r1 (genpatches > 3) ready, both should go stable same time as gentoo-sources. Only tuxonice-sources-2.6.24-r1 should be considered for stabilization wrt this bug, 2.6.23-r10 doesn't patch well (changes in stable branch broke tuxonice) and was removed.
(In reply to comment #17) > Only tuxonice-sources-2.6.24-r1 should be considered for stabilization wrt this > bug Big mistake: above should be 2.6.24-r2 (as -r2 contains fix for userui related problem).
2.6.24 is nowhere near ready to go stable, pending on at least #207383 #208493, and probably a few more that I haven't caught up with yet
I would invite the kernel team to consider commit 900cf086fd2fbad07f72f4575449e0d0958f860f to Linus' tree entitled "Be more robust about bad arguments in get_user_pages()". In particular, consider this remark from its author, Jonathan Corbet: " ... how could a failure to check for *read* access turn into a root exploit? It turns out that it's a buffer overflow problem which is made easy by the way get_user_pages() is coded." He's pointing out that the vmsplice() exploit is, in fact, just an access vector for a vulnerability that really resides in get_user_pages(). Moreover, it is quite plausible that get_user_pages() could be exploited by other presently unknown means in the kernel - for example, according to the PaX author, Direct I/O is a potential candidate but who knows what else ... The aformentioned commit closes this loophole. Jonathan has also written an article about it here, for which a subscription is required until 21st Feb: http://lwn.net/Articles/268783/. I think this patch is a prime candidate for genpatches-base and the stable queue. By committing this we could well be forearmed against future attacks that are based on the same principle. For the commit, see http://tinyurl.com/2l5xal. The patch itself is as follows: diff --git a/mm/memory.c b/mm/memory.c index e5628a5..717aa0e 100644 (file) --- a/mm/memory.c +++ b/mm/memory.c @@ -989,6 +989,8 @@ int get_user_pages(struct task_struct *tsk, struct mm_struct *mm, int i; unsigned int vm_flags; + if (len <= 0) + return 0; /* * Require read or write permissions. * If 'force' is set, we only require the "MAY" flags.
Any news from the suspend2-sources maintainers regarding when a patch will be published?
By the way, why is there still no GLSA about this? Or will they only be published after the bug has been fixed? As a reply comment #21, suspend2 has been renamed to tuxonice, and I understood that the same patch would apply there as would apply to gentoo sources. That's how I'm reading from comment #13 - correct me if I'm wrong (for example, if the stuff in comment #20 changes this somehow).
(In reply to comment #20) > I would invite the kernel team to consider commit > 900cf086fd2fbad07f72f4575449e0d0958f860f thanks, queued. (In reply to comment #22) > By the way, why is there still no GLSA about this? We do not do kernel GLSAs, sorry. Both the security and kernel projects don't have enough resources to coordinate them (too many kernels, and too many vulns because almost any small kernel bug is a vulnerability). We had a couple of developers who attempted to fill the "kernel security" role in the past but they burned out - it's a mindlessly boring unforgiving task which eats hours upon hours. Are you interested? :)
> We do not do kernel GLSAs, sorry. Now that you said it, I noticed that gentoo security handbook says that "Keeping your kernel up-to-date is also recommended." - even though I'm not sure if it really points out that kernel GLSAs don't even exist at all. > it's a mindlessly boring unforgiving task which eats hours upon hours. > Are you interested? :) The description sure sounds tempting :-) I guess I'm going to pass this one...
(In reply to comment #22) > As a reply comment #21, suspend2 has been renamed to tuxonice, and I understood > that the same patch would apply there as would apply to gentoo sources. That's > how I'm reading from comment #13 - correct me if I'm wrong (for example, if the > stuff in comment #20 changes this somehow). Yes, suspend2-sources is p.masked, pending removal. I've contacted Nigel (TuxOnIce upstream) about resyncing patch for 2.6.23.16.
I do think it's a shame about the lack of kernel GLSAs. The original reason was that there was going to be a shiny new tool called KISS, which was obviously much more exciting to work on. That never materialised though. Perhaps not for every little thing - not for example for a DoS in some random RAID controller module only on FooBAR/08 architectures, but for local/remote roots that affect large percentages of users, it would be good. After I've installed a machine, I set up a cron job that emails me the output of glsa-check -l affected, and only update software that's affected. I find it strange that the main, core component that everything else runs on is excluded from the Gentoo **Linux** "Security Advisories". The first I heard of this was on Slashdot, and that's not the best way to get your news. Yes, there are other ways to get this info. Not everyone has time to trawl through mailing lists, and Bugzillas, etc though. GLSAs are a nice method. Anyway, I mentioned this on the security mailing list a couple of times, and got shouted down, so I'll don my suit now.
While you install the kernel sources with emerge, you don't actually install the kernel with emerge, so kernels are treated special. AFAIK glsa-check will only check if you have some vulnerable kernel sources installed and nothing about the running kernel.
I realize there are a metric shitton of kernels in the tree but it seems to me it would make sense to make _some_ attempt to ensure users are aware of things like a root exploit in the Linux part of Gentoo Linux. "It can't be fixed with just emerge blah so we don't GLSA it" is interesting to put it mildly. I'm interested though, maybe I'd even consider a return to Gentoo: why does doing kernel security even vaguely right eat hours upon hours? It's fixed in the tree for at least some kernels, why is it impossible to notify users of which kernels are broken and which are fixed? And do you really think it's a good idea for serious distributions to quietly fix root exploits in the kernel without notifying users?
(In reply to comment #26) > I do think it's a shame about the lack of kernel GLSAs. > The original reason was that there was going to be a shiny new tool called > KISS, which was obviously much more exciting to work on. That never > materialised though. > > Perhaps not for every little thing - not for example for a DoS in some random > RAID controller module only on FooBAR/08 architectures, but for local/remote > roots that affect large percentages of users, it would be good. > > After I've installed a machine, I set up a cron job that emails me the output > of glsa-check -l affected, and only update software that's affected. > > I find it strange that the main, core component that everything else runs on is > excluded from the Gentoo **Linux** "Security Advisories". > > The first I heard of this was on Slashdot, and that's not the best way to get > your news. Yes, there are other ways to get this info. Not everyone has time to > trawl through mailing lists, and Bugzillas, etc though. GLSAs are a nice > method. > > Anyway, I mentioned this on the security mailing list a couple of times, and > got shouted down, so I'll don my suit now. > Well, I won't shout at you, I'll just point you to comment #23 on this bug...I think everyone would like to have kernel GLSA, but remember, unlike Ubuntu or Fedora, here no one gets paid to do the job, and god knows tracking kernel issues on a dozen different patchset is all but an exciting task...
@Jon: You're more than welcome to return to help with kernel security. I'd buy you beer any day I meet you for that:) Wrt informing users I think a news item on the front page and an announce mail is going to happen.
Can we please discuss Gentoo's kernel security process off of this bug? I'm happy for any insights, offers, and ideas, if they go to the security mailing list, or the security@g.o alias. Calum, if you are really interested in helping out within kernel security, please let me know in private.
Of those kernel ebuilds that leverage genpatches-base (all of the 2.6 versions apparently), figuring out which are vulnerable isn't so hard. Let's assume the following: * < 2.6.17 is not vulnerable (debatable) * All other version are except for: 2.6.23 + genpatches-base-2.6.23-9 2.6.24 + genpatches-base-2.6.24-3 Now for a cheeky one-liner to look for those that are vulnerable: $ cd /usr/portage/sys-kernel && find -iname "*.ebuild" -exec grep -H GENPATCHES_VER '{}' \; | cut -d/ -f3- | perl -ne 'm/(.+)\-2\.6\.(\d+)(?:\-r(\d+))?.+?"(\d+)"/ && (($2 >= 17 && $2 < 23) || ($2 == 24 && $4 < 3) || ($2 == 23 && $4 < 9)) && print "$1-2.6-$2" . (($3)?"-r$3":"") . " [genpatches-2.6.$2-$4]\n"' | sort gentoo-sources-2.6-19-r5 [genpatches-2.6.19-6] gentoo-sources-2.6-19-r7 [genpatches-2.6.19-8] gentoo-sources-2.6-20-r10 [genpatches-2.6.20-14] gentoo-sources-2.6-21-r4 [genpatches-2.6.21-6] gentoo-sources-2.6-22 [genpatches-2.6.22-1] gentoo-sources-2.6-22-r1 [genpatches-2.6.22-2] gentoo-sources-2.6-22-r10 [genpatches-2.6.22-11] gentoo-sources-2.6-22-r2 [genpatches-2.6.22-3] gentoo-sources-2.6-22-r3 [genpatches-2.6.22-4] gentoo-sources-2.6-22-r4 [genpatches-2.6.22-5] gentoo-sources-2.6-22-r5 [genpatches-2.6.22-6] gentoo-sources-2.6-22-r6 [genpatches-2.6.22-7] gentoo-sources-2.6-22-r7 [genpatches-2.6.22-8] gentoo-sources-2.6-22-r8 [genpatches-2.6.22-9] gentoo-sources-2.6-22-r9 [genpatches-2.6.22-10] gentoo-sources-2.6-23 [genpatches-2.6.23-1] gentoo-sources-2.6-23-r1 [genpatches-2.6.23-2] gentoo-sources-2.6-23-r2 [genpatches-2.6.23-3] gentoo-sources-2.6-23-r3 [genpatches-2.6.23-4] gentoo-sources-2.6-23-r4 [genpatches-2.6.23-5] gentoo-sources-2.6-23-r5 [genpatches-2.6.23-6] gentoo-sources-2.6-23-r6 [genpatches-2.6.23-7] gentoo-sources-2.6-23-r7 [genpatches-2.6.23-8] gentoo-sources-2.6-24 [genpatches-2.6.24-1] gentoo-sources-2.6-24-r1 [genpatches-2.6.24-2] hardened-sources-2.6-20-r10 [genpatches-2.6.20-19] hardened-sources-2.6-20-r6 [genpatches-2.6.20-13] hardened-sources-2.6-23-r4 [genpatches-2.6.23-6] hardened-sources-2.6-23-r6 [genpatches-2.6.23-7] rsbac-sources-2.6-18 [genpatches-2.6.18-3] rsbac-sources-2.6-18-r1 [genpatches-2.6.18-3] rsbac-sources-2.6-19 [genpatches-2.6.19-5] rsbac-sources-2.6-19-r1 [genpatches-2.6.19-7] rsbac-sources-2.6-21 [genpatches-2.6.21-4] rsbac-sources-2.6-21-r1 [genpatches-2.6.21-4] suspend2-sources-2.6-21-r7 [genpatches-2.6.21-6] suspend2-sources-2.6-22-r2 [genpatches-2.6.22-6] tuxonice-sources-2.6-23 [genpatches-2.6.23-1] tuxonice-sources-2.6-23-r1 [genpatches-2.6.23-2] tuxonice-sources-2.6-23-r2 [genpatches-2.6.23-3] tuxonice-sources-2.6-23-r3 [genpatches-2.6.23-4] tuxonice-sources-2.6-23-r4 [genpatches-2.6.23-4] tuxonice-sources-2.6-23-r5 [genpatches-2.6.23-5] tuxonice-sources-2.6-23-r6 [genpatches-2.6.23-6] tuxonice-sources-2.6-23-r7 [genpatches-2.6.23-7] tuxonice-sources-2.6-23-r8 [genpatches-2.6.23-7] tuxonice-sources-2.6-23-r9 [genpatches-2.6.23-7] tuxonice-sources-2.6-24 [genpatches-2.6.24-1] usermode-sources-2.6-18 [genpatches-2.6.18-1] usermode-sources-2.6-18-r1 [genpatches-2.6.18-8] usermode-sources-2.6-18-r2 [genpatches-2.6.18-8] xen-sources-2.6-18-r6 [genpatches-2.6.18-10] xen-sources-2.6-18-r7 [genpatches-2.6.18-10] xen-sources-2.6-18-r8 [genpatches-2.6.18-10] xen-sources-2.6-20-r5 [genpatches-2.6.20-19] xen-sources-2.6-20-r6 [genpatches-2.6.20-19] I must say that it seems as though a little tree de-crufting wouldn't go amiss. We're missing vserver-sources here as it uses an odd version numbering scheme. Still, a casual glance at all versions in portage makes it plainly obvious that they are vulnerable: $ cd /usr/portage/sys-kernel/vserver-sources && for ebuild in *.ebuild; do CKV=$(grep ^CKV $ebuild | cut -d\" -f2); GPV=$(grep ^K_GENPATCHES_VER $ebuild | cut -d\" -f2); echo "$ebuild [genpatches-base-$CKV-$GPV]"; done vserver-sources-2.2.0-r1.ebuild [genpatches-base-2.6.20-13] vserver-sources-2.2.0.4.ebuild [genpatches-base-2.6.22-10] vserver-sources-2.2.0.5.ebuild [genpatches-base-2.6.22-10] vserver-sources-2.3.0.27.ebuild [genpatches-base-2.6.22-10] vserver-sources-2.3.0.29.ebuild [genpatches-base-2.6.22-10]
*** Bug 209992 has been marked as a duplicate of this bug. ***
(In reply to comment #32) > We're missing vserver-sources here as it uses an odd version numbering scheme. > Still, a casual glance at all versions in portage makes it plainly obvious that > they are vulnerable: > > $ cd /usr/portage/sys-kernel/vserver-sources && for ebuild in *.ebuild; do > CKV=$(grep ^CKV $ebuild | cut -d\" -f2); GPV=$(grep ^K_GENPATCHES_VER $ebuild | > cut -d\" -f2); echo "$ebuild [genpatches-base-$CKV-$GPV]"; done > vserver-sources-2.2.0-r1.ebuild [genpatches-base-2.6.20-13] > vserver-sources-2.2.0.4.ebuild [genpatches-base-2.6.22-10] > vserver-sources-2.2.0.5.ebuild [genpatches-base-2.6.22-10] > vserver-sources-2.3.0.27.ebuild [genpatches-base-2.6.22-10] > vserver-sources-2.3.0.29.ebuild [genpatches-base-2.6.22-10] 2.2.0.6 (just commited) is not vulnerable
Tested per Kerin's IRC request: ======================================== [test@dev-01 ~] uname -a Linux dev-01 2.6.23-hardened-r7 #4 SMP PREEMPT Wed Feb 13 11:55:39 MST 2008 i686 Intel(R) Xeon(TM) CPU 3.06GHz GenuineIntel GNU/Linux [test@dev-01 ~] gcc -static -Wno-format -o milw0rm-5092 copy_from_user_mmap_sem.c [test@dev-01 ~] ./milw0rm-5092 ----------------------------------- Linux vmsplice Local Root Exploit By qaaz ----------------------------------- [+] mmap: 0x0 .. 0x1000 [+] page: 0x0 [+] page: 0x20 [+] mmap: 0x4000 .. 0x5000 [+] page: 0x4000 [+] page: 0x4020 [+] mmap: 0x1000 .. 0x2000 [+] page: 0x1000 [+] mmap: 0x57ed9000 .. 0x57f0b000 [-] vmsplice: Bad address [test@dev-01 ~] gcc -static -Wno-format -o milw0rm-5093 vmsplice_to_pipe.c [test@dev-01 ~] ./milw0rm-5093 ----------------------------------- Linux vmsplice Local Root Exploit By qaaz ----------------------------------- [+] addr: 0x16b64 [-] wtf ======================================== Couldn't get milw0rm 5092 (CVE-2008-0600) to get to 'wtf'. I have turned off CONFIG_PAX_UDEREF, CONFIG_PAX_ASLR, and CONFIG_GRKERNSEC_HIDESYM, as well as made /proc/kallsyms world-readable. So, 0010 and 0600 (copy_from_user_mmap_sem and vmsplice_to_pipe, respectively) were tested, but I couldn't find any code against 0009 (vmsplice_to_user).
*** Bug 210156 has been marked as a duplicate of this bug. ***
both fixes are in rsbac-sources-2.6.23 on cvs ~arch as well now (note, the fix is in the RSBAC patch so checking genpatch version will be unaccurate for this one)
*** Bug 210263 has been marked as a duplicate of this bug. ***
*** Bug 210451 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > Yes, suspend2-sources is p.masked, pending removal. I've contacted Nigel > (TuxOnIce upstream) about resyncing patch for 2.6.23.16. tuxonice-sources-2.6.23-r10.ebuild: Revision bump for genpatches 9, TuxOnIce 3.0-rc5 for 2.6.23.16.
vserver-sources-2.2.0.6 stable, vulnerable versions removed, devel branch 2.3 is not fixed yet but masked anyway for testing
Adding a reference to CVE-2008-0600 to the summary. I have no idea why it wasn't there before but it should be.
hppa, seems that your kernel is still affected by this bug. Please check this bug, to avoid release with this flaw. Thank you.
(In reply to comment #43) > hppa, seems that your kernel is still affected by this bug. Please check this > bug, to avoid release with this flaw. Thank you. If you mean hppa-sources, that's package.masked in accordance with bug #202391.
Ah, I see. Thank you Jeroen. UnCC'ing hppa. Then seems that the only affected kernels remain are: cell-sources, mips-sources, usermode-sources. CC'ing maintainers: please check your kernels. I think it's worth to have this this bug fixed even if kernels are security unsupported/unstable... Thank you in advance.
cell sources could be p.masked since .24 has most of the code needed to get a bootable ps3/cell system and I still prefer tracking the git branch. If the other people in the team want I could try to get a .25 snapshot.
(In reply to comment #46) > If the other people in the team want I could try to get a .25 snapshot. > IMHO, less kernels to maintain (and track bugs in) is better than more. If you think 2.6.24 contains enough support for cell, I would be for masking this,
I added an updated .24.3+cell/ps3 related improvement, that should solve the issue for cell-sources.
cell-sources and usermode-sources are not so important for release. So we are done with this bug.
there are no more vulnerable versions of vserver-sources
For a long time, recent mips sources have this issues fixed ...
There are no longer any 2.x kernels available in the repository with the exception of sys-kernel/xbox-sources which is unsupported by security.
