login
Search
Patches for a much publicized Linux kernel local root exploit were released today as 2.6.24.2, 2.6.23.16, and 2.6.22.18. The latest bug, labeled as CVE-2008-0600, was introduced by the vmsplice() system call and added into the 2.6 kernel in 2.6.17. It is the third in a series of root exploits surrounding the same system call, the two earlier bugs being CVE-2008-0009 and CVE-2008-0010. Easily obtained exploits exist for both the older CVE-2008-0010 which affected the 2.6.23 and 2.6.24 kernels, and the latest CVE-2008-0600, allowing a local non-root user to gain root permissions.
From: Niki Denev <ndenev@...> Subject: kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit Date: Feb 10, 2:04 am 2008Hi,
As the subject says the 2.6.24.1 is still vulnerable to the vmsplice
local root exploit.[opa@test tmp]$ uname -a
Linux tester 2.6.24.1 #1 Sun Feb 10 00:06:49 EST 2008 i686 unknown
[opa@test tmp]$ ./vms-----------------------------------
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: 0xb7f56000 .. 0xb7f88000
[+] root
[root@test tmp]#
[root@test tmp]# id
uid=0(root) gid=0(root) groups=2033(opa)
[root@test tmp]# uname -a
Linux test 2.6.24.1 #1 Sun Feb 10 00:06:49 EST 2008 i686 unknownIs there any known fix/patch for this?
--
From: Willy Tarreau <w@...> Subject: Re: kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit Date: Feb 10, 2:32 am 2008On Sun, Feb 10, 2008 at 08:04:35AM +0200, Niki Denev wrote:
> Hi,
>
> As the subject says the 2.6.24.1 is still vulnerable to the vmsplice
> local root exploit.Yes indeed, that's quite bad. 2.6.24-git is still vulnerable too, and
also contains the fix :-(CC'd Jens as he worked on the fix.
Willy
--
From: Niki Denev <ndenev@...> Subject: Re: kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit Date: Feb 10, 2:38 am 2008On Feb 10, 2008 8:32 AM, Willy Tarreau wrote:
> On Sun, Feb 10, 2008 at 08:04:35AM +0200, Niki Denev wrote:
> > Hi,
> >
> > As the subject says the 2.6.24.1 is still vulnerable to the vmsplice
> > local root exploit.
>
> Yes indeed, that's quite bad. 2.6.24-git is still vulnerable too, and
> also contains the fix :-(
>
> CC'd Jens as he worked on the fix.
>
> Willy
>
>I was unable to gain root on 2.6.24-git20
but after several segfaults when executing the exploit continously
the machine crashes.--Niki
--
From: Niki Denev <ndenev@...> Subject: Re: [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit Date: Feb 10, 5:40 am 2008On Feb 10, 2008 1:38 AM, Niki Denev wrote:
>
> On Feb 10, 2008 8:32 AM, Willy Tarreau wrote:
> > On Sun, Feb 10, 2008 at 08:04:35AM +0200, Niki Denev wrote:
> > > Hi,
> > >
> > > As the subject says the 2.6.24.1 is still vulnerable to the vmsplice
> > > local root exploit.
> >
> > Yes indeed, that's quite bad. 2.6.24-git is still vulnerable too, and
> > also contains the fix :-(
> >
> > CC'd Jens as he worked on the fix.
> >
> > Willy
> >
> >
>
> I was unable to gain root on 2.6.24-git20
> but after several segfaults when executing the exploit continously
> the machine crashes.
>
> --Niki
>this fixed the problem for me (kernel 2.6.24.1) :
It appears that the initial patch checked the input to vmsplice_to_user,
but the exploit used vmsplice_to_pipe which remained open to the attack.--- fs/splice.c.orig 2008-02-08 21:55:30.000000000 +0200
+++ fs/splice.c 2008-02-10 11:32:50.000000000 +0200
@@ -1443,6 +1443,10 @@
struct pipe_inode_info *pipe;
struct page *pages[PIPE_BUFFERS];
struct partial_page partial[PIPE_BUFFERS];
+ int error;
+ long ret;
+ void __user *base;
+ size_t len;
struct splice_pipe_desc spd = {
.pages = pages,
.partial = partial,
@@ -1450,6 +1454,31 @@
.ops = &user_page_pipe_buf_ops,
};+ error = ret = 0;
+
+ /*
+ * Get user address base and length for this iovec.
+ */
+ error = get_user(base, &iov->iov_base);
+ if (unlikely(error))
+ return error;
+ error = get_user(len, &iov->iov_len);
+ if (unlikely(error))
+ return error;
+
+ /*
+ * Sanity check this iovec. 0 read succeeds.
+ */
+ if (unlikely(!len))
+ return 0;
+ if (unlikely(!base)) {
+ return -EFAULT;
+ }
+
+ if (unlikely(!access_ok(VERIFY_WRITE, base, len))) {
+ return -EFAULT;
+ }
+
pipe = pipe_info(file->f_path.dentry->d_inode);
if (!pipe)
return -EBADF;
--
From: Bastian Blank <bastian@...> Subject: Re: [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit Date: Feb 10, 8:22 am 2008On Sun, Feb 10, 2008 at 04:40:53AM -0500, Niki Denev wrote:
> this fixed the problem for me (kernel 2.6.24.1) :
> It appears that the initial patch checked the input to vmsplice_to_user,
> but the exploit used vmsplice_to_pipe which remained open to the attack.This patch is broken. It opens the old hole again.
> @@ -1450,6 +1454,31 @@
> .ops = &user_page_pipe_buf_ops,
> };
>
> + error = ret = 0;
> +
> + /*
> + * Get user address base and length for this iovec.
> + */
> + error = get_user(base, &iov->iov_base);
> + if (unlikely(error))
> + return error;
> + error = get_user(len, &iov->iov_len);
> + if (unlikely(error))
> + return error;iov is unchecked.
> + if (unlikely(!access_ok(VERIFY_WRITE, base, len))) {
> + return -EFAULT;
> + }Use VERIFY_READ and this only checks the first entry.
I checked the following patch and it at least fixes the known exploit.
diff --git a/fs/splice.c b/fs/splice.c
index 14e2262..80beb2b 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1237,6 +1237,11 @@ static int get_iovec_page_array(const struct iovec __user *iov,
if (unlikely(!base))
break;+ if (!access_ok(VERIFY_READ, base, len)) {
+ error = -EFAULT;
+ break;
+ }
+
/*
* Get this base offset and number of pages, then map
* in the user pages.
--
Even historians fail to learn from history -- they repeat the same mistakes.
-- John Gill, "Patterns of Force", stardate 2534.7
--
From: Niki Denev <ndenev@...> Subject: Re: [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit Date: Feb 10, 8:39 am 2008On Feb 10, 2008 12:22 PM, Bastian Blank wrote:
> On Sun, Feb 10, 2008 at 04:40:53AM -0500, Niki Denev wrote:
> > this fixed the problem for me (kernel 2.6.24.1) :
> > It appears that the initial patch checked the input to vmsplice_to_user,
> > but the exploit used vmsplice_to_pipe which remained open to the attack.
>
> This patch is broken. It opens the old hole again.
>
> > @@ -1450,6 +1454,31 @@
> > .ops = &user_page_pipe_buf_ops,
> > };
> >
> > + error = ret = 0;
> > +
> > + /*
> > + * Get user address base and length for this iovec.
> > + */
> > + error = get_user(base, &iov->iov_base);
> > + if (unlikely(error))
> > + return error;
> > + error = get_user(len, &iov->iov_len);
> > + if (unlikely(error))
> > + return error;
>
> iov is unchecked.
>
> > + if (unlikely(!access_ok(VERIFY_WRITE, base, len))) {
> > + return -EFAULT;
> > + }
>
> Use VERIFY_READ and this only checks the first entry.
>
> I checked the following patch and it at least fixes the known exploit.
>
> diff --git a/fs/splice.c b/fs/splice.c
> index 14e2262..80beb2b 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -1237,6 +1237,11 @@ static int get_iovec_page_array(const struct iovec __user *iov,
> if (unlikely(!base))
> break;
>
> + if (!access_ok(VERIFY_READ, base, len)) {
> + error = -EFAULT;
> + break;
> + }
> +
> /*
> * Get this base offset and number of pages, then map
> * in the user pages.
> --
> Even historians fail to learn from history -- they repeat the same mistakes.
> -- John Gill, "Patterns of Force", stardate 2534.7
>This patch is against 2.6.24.1 which has already the fix to vmsplice_to_user
With it i can't exploit the hole, and it is returns "invalid address"
--
From: Bastian Blank <bastian@...> Subject: Re: [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit Date: Feb 10, 8:47 am 2008On Sun, Feb 10, 2008 at 12:39:05PM +0000, Niki Denev wrote:
> This patch is against 2.6.24.1 which has already the fix to vmsplice_to_user
> With it i can't exploit the hole, and it is returns "invalid address"This is the vmsplice_to_pipe path and I have many reports that it is not
fixed.Bastian
--
If there are self-made purgatories, then we all have to live in them.
-- Spock, "This Side of Paradise", stardate 3417.7
--
From: Oliver Pinter <oliver.pntr@...> Subject: Re: [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit Date: Feb 10, 9:02 am 2008thx it fixed for 2.6.22
>>>>>>>
commit f6e993b835393543bab2d917f9dea75218473edd
Author: Oliver Pinter
Date: Sun Feb 10 14:03:46 2008 +0100[PATCH] vm: splice local root exploit fix for 2.6.22.y
Based on Bastian Blank's patch
Fix for CVE_2008_0009 and CVE_2008-0010
----->8-----
oliver@pancs:/tmp$ ./2617_26241_root_exploit
-----------------------------------
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: 0xb7f1a000 .. 0xb7f4c000
[-] vmsplice: Bad address-----8<-----
Signed-off-by: Oliver Pinter
diff --git a/fs/splice.c b/fs/splice.c
index e263d3b..d8b106e 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1182,6 +1182,12 @@ static int get_iovec_page_array(const struct
iovec __user *iov,
if (unlikely(!base))
break;+ /* CVE-2008-0009, CVE-2008-0010 fix */
+ if(!access_ok(VERIFY_READ, base, len)) {
+ error = -EFAULT;
+ break;
+ }
+
/*
* Get this base offset and number of pages, then map
* in the user pages.<<<<<<<
On 2/10/08, Bastian Blank wrote:
> On Sun, Feb 10, 2008 at 12:39:05PM +0000, Niki Denev wrote:
> > This patch is against 2.6.24.1 which has already the fix to
> vmsplice_to_user
> > With it i can't exploit the hole, and it is returns "invalid address"
>
> This is the vmsplice_to_pipe path and I have many reports that it is not
> fixed.
>
> Bastian
>
> --
> If there are self-made purgatories, then we all have to live in them.
> -- Spock, "This Side of Paradise", stardate 3417.7
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>oliver@pancs:/tmp$ ./2617_26241_root_exploit
-----------------------------------
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: 0xb7f1a000 .. 0xb7f4c000
[-] vmsplice: Bad addres--
Thanks,
Oliver
--
From: Greg KH <greg@...> Subject: Re: [stable] [PATCH] kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit Date: Feb 10, 1:05 pm 2008On Sun, Feb 10, 2008 at 02:02:27PM +0100, Oliver Pinter wrote:
> thx it fixed for 2.6.22
>
> >>>>>>>
>
> commit f6e993b835393543bab2d917f9dea75218473edd
> Author: Oliver Pinter
> Date: Sun Feb 10 14:03:46 2008 +0100
>
> [PATCH] vm: splice local root exploit fix for 2.6.22.y
>
> Based on Bastian Blank's patch
>
> Fix for CVE_2008_0009 and CVE_2008-0010
>
> ----->8-----
>
> oliver@pancs:/tmp$ ./2617_26241_root_exploit
> -----------------------------------
> 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: 0xb7f1a000 .. 0xb7f4c000
> [-] vmsplice: Bad address
>
> -----8<-----
>
> Signed-off-by: Oliver Pinter
>
> diff --git a/fs/splice.c b/fs/splice.c
> index e263d3b..d8b106e 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -1182,6 +1182,12 @@ static int get_iovec_page_array(const struct
> iovec __user *iov,
> if (unlikely(!base))
> break;
>
> + /* CVE-2008-0009, CVE-2008-0010 fix */No, this is a different CVE, as it is a different problem from the
original 09 and 10 report.It has been given CVE-2008-0600 to address this issue (09 and 10 only
affect .23 and .24 kernels, and have been fixed.)> + if(!access_ok(VERIFY_READ, base, len)) {
> + error = -EFAULT;
> + break;
> + }Hm, perhaps we should just properly check the len field instead? That's
what is being overflowed here...thanks,
greg k-h
--
From: Greg Kroah-Hartman <gregkh@...> Subject: Linux 2.6.24.2 Date: Feb 11, 2:22 am 2008We (the -stable team) are announcing the release of the 2.6.24.2
kernel.It fixes one thing, CVE-2008-0600.
All users of the 2.6.24 series, with untrusted local users are strongly
encouraged to upgrade.I'll also be replying to this message with a copy of the patch between
2.6.24.1 and 2.6.24.2The updated 2.6.24.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.24.y.git
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=su...thanks,
greg k-h
--------
Makefile | 2 +-
fs/splice.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)Summary of changes from v2.6.24.1 to v2.6.24.2
==============================================Bastian Blank (1):
splice: fix user pointer access in get_iovec_page_array()Greg Kroah-Hartman (1):
Linux 2.6.24.2--
From: Greg Kroah-Hartman <gregkh@...> Subject: Linux 2.6.23.16 Date: Feb 11, 2:26 am 2008We (the -stable team) are announcing the release of the 2.6.23.16
kernel.It fixes one thing, CVE-2008-0600.
All users of the 2.6.23 series, with untrusted local users are strongly
encouraged to upgrade.I'll also be replying to this message with a copy of the patch between
2.6.23.15 and 2.6.23.16The updated 2.6.23.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=su...thanks,
greg k-h
--------
Makefile | 2 +-
fs/splice.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)Summary of changes from v2.6.23.15 to v2.6.23.16
================================================Bastian Blank (1):
splice: fix user pointer access in get_iovec_page_array()Greg Kroah-Hartman (1):
Linux 2.6.23.16--
From: Greg Kroah-Hartman <gregkh@...> Subject: Linux 2.6.22.18 Date: Feb 11, 3:43 am 2008We (the -stable team) are announcing the release of the 2.6.22.18
kernel.It fixes one thing, CVE-2008-0600.
All users of the 2.6.22 series, with untrusted local users are strongly
encouraged to upgrade.I'll also be replying to this message with a copy of the patch between
2.6.22.17 and 2.6.22.18The updated 2.6.22.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=su...thanks,
greg k-h
--------
Makefile | 2 +-
fs/splice.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)Summary of changes from v2.6.22.17 to v2.6.22.18
================================================Bastian Blank (1):
splice: fix user pointer access in get_iovec_page_array() (CVE-2008-0600)Greg Kroah-Hartman (1):
Linux 2.6.22.18--
Am I missing something?
What a fuzz.... :D
I've tried that exploit on a set of machines varying in 2.6.19, 2.6.22 and 2.6.23. Not EVEN ONE of them failed. Exploit got zombiefied. That's all. The only damage I've got: lock-ups after trying to KILL zombies.
Which means?
So are you saying that the exploit worked on all three kernels you tried? Or that it didn't? I'll be honest and say I'm not sure what you said. (From what I heard, it should work on all three kernels you mentioned.0
--
Program Intellivision and play Space Patrol!
Exploit
This exploit worked exactly as advertised on my .22 machines. I had some problems with my .19 machines as it seems to have a problem trapping and executing the exploit code. Seems to be having a problem creating the pipe as expected to run the exit_code needed to get the root prompt. On my .18 mahcines, it caused a kernel panic. Nothing on the console nor the logs.
Now, I'm having a problem patching my .22 kernel. Can anyone point me to some link about patching the kernel. I've honestly have never done this before.
Thanks
One interesting thing about
One interesting thing about this vulnerability is, it was found in new, freshly written code. When you look at the security track record of other operating systems, you'll see that pretty much all the exploitable bugs are found in old code, created years ago when developers didn't really care about security that much.