Hi,
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 unknown
Is there any known fix/patch for this?
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
On Feb 10, 2008 8:32 AM, Willy Tarreau <[email protected]> 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
On Feb 10, 2008 1:38 AM, Niki Denev <[email protected]> wrote:
>
> On Feb 10, 2008 8:32 AM, Willy Tarreau <[email protected]> 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;
hmmm, with 2.6.22.y serie is too affected
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Feb 9 15:34:35 2008
oliver@home:~$ ./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: 0xb7f79000 .. 0xb7fab000
[+] root
root@home:~# uname -a
Linux home 2.6.22.17 #3 SMP PREEMPT Mon Feb 4 17:38:33 CET 2008 i686 GNU/Linux
root@home:~#
--
Thanks,
Oliver
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
On Feb 10, 2008 12:22 PM, Bastian Blank <[email protected]> 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"
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
On Feb 10, 2008 12:47 PM, Bastian Blank <[email protected]> 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
Exactly, my patch is for the the vmsplice_to_pipe path.
I don't guarantee correctness, but it stops the exploit in my environment.
Niki
thx it fixed for 2.6.22
>>>>>>>
commit f6e993b835393543bab2d917f9dea75218473edd
Author: Oliver Pinter <[email protected]>
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 <[email protected]>
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 <[email protected]> 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 [email protected]
> 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
On Feb 10, 2008 12:22 PM, Bastian Blank <[email protected]> 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
>
As far as i can see, at least on x86 and x86_64 the first argument to
access_ok : (VERIFY_READ|VERIFY_WRITE) is ignored.
Also even if it is used on different arch, using WRITE instead of READ
should be safe because WRITE is a superset of READ.
You are right that it only catches the first entry.
--Niki
On Sun, Feb 10, 2008 at 02:02:27PM +0100, Oliver Pinter wrote:
> thx it fixed for 2.6.22
>
> >>>>>>>
>
> commit f6e993b835393543bab2d917f9dea75218473edd
> Author: Oliver Pinter <[email protected]>
> 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 <[email protected]>
>
> 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
On Feb 10, 2008 7:05 PM, Greg KH <[email protected]> wrote:
> 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...
Sorry, I forgot to cc you on this one:
http://lkml.org/lkml/2008/2/10/153
I don't see where the current code is checking that base is
accessible. We just check that we can copy the struct iovecs, right?
Pekka
simple len and base check is already in kernel:
2.6.22.17 @ 1176,2-16 - fs/splice.c
/*
* Sanity check this iovec. 0 read succeeds.
*/
if (unlikely(!len))
break;
error = -EFAULT;
if (unlikely(!base))
break;
On 2/10/08, Greg KH <[email protected]> wrote:
> On Sun, Feb 10, 2008 at 02:02:27PM +0100, Oliver Pinter wrote:
> > thx it fixed for 2.6.22
> >
> > >>>>>>>
> >
> > commit f6e993b835393543bab2d917f9dea75218473edd
> > Author: Oliver Pinter <[email protected]>
> > 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 <[email protected]>
> >
> > 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
>
--
Thanks,
Oliver
thanks the info
On 2/10/08, Greg KH <[email protected]> wrote:
> On Sun, Feb 10, 2008 at 02:02:27PM +0100, Oliver Pinter wrote:
> > thx it fixed for 2.6.22
> >
> > >>>>>>>
> >
> > commit f6e993b835393543bab2d917f9dea75218473edd
> > Author: Oliver Pinter <[email protected]>
> > 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 <[email protected]>
> >
> > 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
>
--
Thanks,
Oliver