Bugzilla Bug 209460

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 an attachment (id=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 an attachment (id=143165) [details]
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 ...