Local root exploit in kernel 2.6.17 - 2.6.24 (vmsplice)

[Hirvinen]

https://bugs.gentoo.org/show_bug.cgi?id=209460 works on at least Hardy 2.6.24-7, Edgy 2.6.17-12, but not on Feisty 2.6.20-16.

[slava (slava-linux-kernel-bugs)]

Latest working kernel version:
Earliest failing kernel version: 2.6.17
Distribution: Gentoo
Hardware Environment:
Software Environment:
Problem Description:
Two root exploits have been reported:
http://milw0rm.com/exploits/5093
http://milw0rm.com/exploits/5092

Both exploits cause kernel Oops or (randomly) give root privilegies to the user.

Here is the same bug reported in gentoo bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=209460

Steps to reproduce:
Compile and run the exploit.

[dsd (dsd-linux-kernel-bugs)]

Assuming this is about CVE-2008-0009/10, this is fixed with "[PATCH] splice: missing user pointer access verification" which is included in 2.6.24.1 and 2.6.23.15. If someone can confirm my assumption, please close this bug.

[tm (tm-linux-kernel-bugs)]

It's not properly fixed in 2.6.24.1. E.g. see http://bugs.gentoo.org/show_bug.cgi?id=209460

[dsd (dsd-linux-kernel-bugs)]

http://bugzilla.kernel.org/show_bug.cgi?id=9924

> It's not properly fixed in 2.6.24.1. E.g. see
> http://bugs.gentoo.org/show_bug.cgi?id=209460

Indeed, I can confirm this.

2.6.24.1 fixes this exploit:
http://milw0rm.com/exploits/5093
(labelled "Diane Lane ...")

but does not fix this one, which still gives me root access on 2.6.24.1:
http://milw0rm.com/exploits/5092
("jessica_biel_naked_in_my_bed.c")

alternative link to the still-working exploit:
http://bugs.gentoo.org/attachment.cgi?id=143059&action=view

Daniel

[rpilar (rpilar-linux-kernel-bugs)]

This is NOT fixed in 2.6.24.1: http://www.securityfocus.com/data/vulnerabilities/exploits/27704.c
But this probably is: http://www.securityfocus.com/data/vulnerabilities/exploits/27704-2.c (at least I can't reproduce it).

Linux Rimmer 2.6.24.1 #4 SMP PREEMPT Sat Feb 9 16:50:17 CET 2008 i686 GNU/Linux

[dsd (dsd-linux-kernel-bugs)]

I have personally tested both exploits under a recent 2.6.22 release,
latest 2.6.23 and latest 2.6.24. Results:

http://milw0rm.com/exploits/5093 ("diane_lane")
This was a bug added in 2.6.23, still present in 2.6.24, but fixed by
the most recent -stable releases for both branches:
- Not exploitable in 2.6.22.10
- Not exploitable in 2.6.23.15
- Not exploitable in 2.6.24.1
so this one is done and dusted...

http://milw0rm.com/exploits/5092 ("jessica_biel")
alt link: http://bugs.gentoo.org/attachment.cgi?id=143059&action=view
This is still exploitable in the latest kernel releases and the exploit
source suggests it has been present since 2.6.17
- Exploitable in 2.6.22.10
- Exploitable in 2.6.23.15
- Exploitable in 2.6.24.1

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

On Sun, Feb 10, 2008 at 11:28:51AM +0000, Daniel Drake wrote:
> I have personally tested both exploits under a recent 2.6.22 release,
> latest 2.6.23 and latest 2.6.24. Results:

There's a fix/explanation proposed for the other one on linux-kernel

[Philip (philip-redhat-bugs)]

Description of problem:

Local user can obtain root access (as described below).

This bug is being actively exploited in the wild -- our server was just broken
in to by an attacker using it. (They got a user's password by previously
compromising a machine somewhere else where that user had an account, and
installed a modified ssh binary on it to record user names and passwords. Then
they logged in to our site as that user, exploited CVE-2008-0010, and became root).

It is EXTREMELY urgent that a fixed kernel be provided ASAP given that this bug
is being actively exploited in the wild.

There is a fix listed upstream in 2.6.23.15 and 2.6.24.1. However, even after
applying that patch and recompiling the kernel, the escalation-of-privilege
exploit still worked so I am wondering if 2.6.23.15 does not completely fix it.

Version-Release number of selected component (if applicable):

All 2.6.23.x kernels

How reproducible: 100%

Steps to Reproduce:
1. Download http://downloads.securityfocus.com/vulnerabilities/exploits/27704.c
2. cc -o exploit 27704.c
3. [as non-privileged user] ./exploit

Actual results:

Root shell

Expected results:

No root shell.

Additional info:

When I altered the kernel spec file for 2.6.23.14-115.fc8 to pull 2.6.23.15
instead of 2.6.23.14 (and altered linux-2.6-highres-timers.patch to apply
cleanly, and removed the already-included-in-2.6.23.15 patches
linux-2.6-net-silence-noisy-printks.patch and
linux-2.6-freezer-fix-apm-emulation-breakage.patch), rebuilt a new kernel RPM,
installed it, and rebooted, the above exploit still worked. So it is possible an
additional patch is needed against 2.6.23, unless I just goofed somehow in my
kernel rebuild. (I did check and the file fs/splice.c was correctly patched and
included the lines that were suppose to fix this problem...)

[Bojan (bojan-redhat-bugs)]

I see 2.6.23.15 has been built in Koji. When is this going to get pushed into
stable updates?

[Heikki Mäntysaari (heikki-mantysaari)]

I can confirm this in Gutsy:

$ gcc exploit.c -o exploit
$ whoami
heikki
$ ./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: 0xb7d90000 .. 0xb7dc2000
[+] root
$ whoami
root

Kernel 2.6.22-14-generic

[Aapo Rantalainen (aapo-rantalainen)]

I confirm this in Hardy Heron
kernel 2.6.24-7-generic

[Pavel (pavel-redhat-bugs)]

*** Bug 432244 has been marked as a duplicate of this bug. ***

[Risto H. Kurppa (risto.kurppa)]

Confirm on Gutsy:
rhk@rubert:~$ gcc exploit2.c -o exploit2
rhk@rubert:~$ ./exploit2
-----------------------------------
 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: 0xb7e04000 .. 0xb7e36000
[+] root
root@rubert:~# uname -a
Linux rubert 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux
root@rubert:~#

[Martin Peeks (martinp23)]

http://bugzilla.kernel.org/show_bug.cgi?id=9924

Also able to confirm on Hardy.

[mjc (mjc-redhat-bugs)]

A new system call named vmsplice() was introduced in the 2.6.17
release of the Linux kernel.

COSEINC reported two issues affecting vmsplice, CVE-2008-0009 and CVE-2008-0010.

On Saturday 20080210 a public exploit was released that utilised a similar flaw
in vmsplice (vmsplice_to_pipe function) to allow a local user to gain privileges
on some architectures.

See also
http://marc.info/?t=120263655300003&r=1&w=2

This issue will affect kernels 2.6.17+ and therefore affected Red Hat Enterprise
Linux 5, but not Red Hat Enterprise Linux 4, 3, or 2.1.

[Pavel (pavel-redhat-bugs)]

Relevant information about patch: http://lkml.org/lkml/2008/2/10/118

[Pavel (pavel-redhat-bugs)]

Relevant discussion at gmane.linux.kernel mailing list:
http://thread.gmane.org/gmane.linux.kernel/637339

[Jon (jon-redhat-bugs)]

Bringing in RH Security Response team.

[dsd (dsd-linux-kernel-bugs)]

fixed in Linus' tree as 712a30e63c8066ed84385b12edbfb804f49cbc44

[mjc (mjc-redhat-bugs)]

Note that there may be a little confusion as there are actually three vmsplice
issues:

CVE-2008-0009 is already fixed upstream, does not affect any RHEL, has no
public exploit. Upstream patch is the second hunk of:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8811930dc74a503415b35c4a79d14fb0b408a361

CVE-2008-0010 is already fixed upstream, does not affect any RHEL, but has
a public exploit. ( http://www.milw0rm.com/exploits/5093 )
Upstream patch is the first hunk of:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8811930dc74a503415b35c4a79d14fb0b408a361

CVE-2008-0600 is not yet fixed upstream, affects RHEL5,
and has a public exploit ( http://www.milw0rm.com/exploits/5092 )

[tonfa (bboissin)]

actually the bug exploitable from 2.6.17-2.6.24 is CVE-2008-0600. CVE-2008-0009/10 only affect
.23 and .24 (so only hardy is affected)

see http://lkml.org/lkml/2008/2/10/177 for details

(btw this bug is pretty scary, it works almost anywhere you can have a shell...)

[mjc (mjc-redhat-bugs)]

Proposed patch for RHEL5 from Al Viro

diff -urN linux-2.6.18.x86_64/fs/splice.c linux-2.6.18.x86_64-fix/fs/splice.c
--- linux-2.6.18.x86_64/fs/splice.c 2008-02-10 11:08:19.000000000 -0500
+++ linux-2.6.18.x86_64-fix/fs/splice.c 2008-02-10 11:31:06.000000000 -0500
@@ -1154,6 +1154,9 @@
                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.

[Iulian Udrea (iulian)]

Confirmed in Hardy - 2.6.24

[Philip (philip-redhat-bugs)]

I can confirm that applying the patch at the bottom of
http://lkml.org/lkml/2008/2/10/118 (thanks, Pavel!), as well as applying the
patch in 2.6.23.15/2.6.24.1, does indeed prevent the published exploit from
working on our system.

Whether or not it closes all attack vectors, it is probably worth pushing out at
least as an interim update since it prevents the published exploit from working
and that published exploit is being actively exploited in the wild.

Note that I believe a new CVE identifier has been assigned for the vulnerability
that 2.6.23.15/2.6.24.1 does not fix: CVE-2008-0600

Also note that, unlike CVE-2008-0009/0010, this is not specific to the
2.6.23/2.6.24 kernels. Older kernels are vulnerable too (including, for example,
2.6.18-53.1.4.el5 -- on that kernel, it is necessary to add
#define PAGE_SIZE getpagesize() to the published exploit, but with that addition
it works to get an instant root shell.)

I am *extremely* thankful this is only a local escalation-of-privilege and not a
remote root. It's bad enough as it is given what seems to be a significant
number of machines out there with hacked-up ssh/sshd binaries that record user
names and passwords, but a remote root being exploited in the wild like this
well before a working patch would be a nightmare!

[Václav Šmilauer (eudoxos)]

I confirm that on hardy and gutsy. I also confirm that the hotfix referenced in debian bugreport http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953 which sets the first byte of sys_vmsplice to RET in /dev/mem ( http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c ) works and prevents the exploit from functioning. I don't know if having that function returning can otherwise adversely affect the system, though.

[Mark (mark-redhat-bugs)]

Fixing CVE name, the exploit "jessica_biel" is for CVE-2008-0600

[Mark (mark-redhat-bugs)]

*** Bug 432263 has been marked as a duplicate of this bug. ***

[mjc (mjc-redhat-bugs)]

Confirmed the patch blocks this issue for Red Hat Enterprise Linux 5; this
specific exploit prints "[-] vmsplice: Bad address" and fails.

[Mark (mark-redhat-bugs)]

So to fix this you need 2.6.24.1 +
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44

or if backporting, an earlier kernel plus both
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8811930dc74a503415b35c4a79d14fb0b408a361
and
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44

[mjc (mjc-redhat-bugs)]

Upstream fix:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44

[Paul Sladen (sladen)]

RHEL tracker is at: https://bugzilla.redhat.com/show_bug.cgi?id=432251 but LP won't allow adding a second entry (in addition to the one for Fedora).

[mjc (mjc-redhat-bugs)]

For Red Hat Enterprise Linux 5:
CVSS v2 Base score: 7.2 (High) (AV:L/AC:L/Au:N/C:C/I:C/A:C)

[Ante Karamatić (ivoks)]

Gutsy/amd64 is affected too.

[sancheztavo (sancheztavo)]

Confirmed in Gutsy. Kernel 2.6.22-14-generic

[Ante Karamatić (ivoks)]

Upstream fix:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44

[Andrew Martin (werdz)]

Confirmed on feisty AMD64 (i386 isn't affected, AMD64 is).

[redhat (redhat-redhat-bugs)]

We added a quick and dirty patch for the problem here:
http://home.powertech.no/oystein/ptpatch2008/

It is a kernel module that disables vmsplice, and logs any attempts to exploit
the bug.
As it it a loadable module it can easily be deployed on systems that can not be
updated with a new kernel for various reasons.

[Ante Karamatić (ivoks)]

I also confirm that suggested hotfix fixes the problem until next reboot, of course.

[seva (seva-redhat-bugs)]

Ola,

I tried that module on a test system and got:
  <name> kernel: general protection fault: 0000 [1] SMP

[steve.tardonia (steve-tardonia-deactivatedaccount)]

steve@genesis:~/bin$ gcc exploitsrv.c -o exploitsrv
steve@genesis:~/bin$ whoami
steve
steve@genesis:~/bin$ ./exploitsrv
-----------------------------------
 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: 0xb7e44000 .. 0xb7e76000
[+] root
root@genesis:~/bin# uname -a
Linux genesis 2.6.22-14-server #1 SMP Fri Feb 1 05:28:54 UTC 2008 i686 GNU/Linux
root@genesis:~/bin#

[Kees Cook (kees)]

The Security Team is working on getting the fix built up. We should have updated kernels available shortly.

[Luis Alcaraz Leal (lalcaraz)]

Luis Alcaraz (Mexico)
Confirmed on Ubuntu 7.10 2.6.22-14-generic
---
lalcaraz@lalcaraz-laptop:~$ vim exploit.c
lalcaraz@lalcaraz-laptop:~$ gcc exploit.c -o exploit
lalcaraz@lalcaraz-laptop:~$ whoami
lalcaraz
lalcaraz@lalcaraz-laptop:~$ ./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: 0xb7e29000 .. 0xb7e5b000
[+] root
root@lalcaraz-laptop:~# whoami
root
root@lalcaraz-laptop:~# uname -a
Linux lalcaraz-laptop 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux
root@lalcaraz-laptop:~#

[Chuck (chuck-redhat-bugs)]

Fixed in:

kernel-2.6.24.1-28.fc9
kernel-2.6.23.15-137.fc8
kernel-2.6.23.15-80.fc7

[ryan (ryan-redhat-bugs-1)]

The make file required some modification for PAE kernels due to path issues;
once compiled module fails to load with:
insmod: error inserting 'ptpatch2008.ko': -1 Invalid module format

(double checked to confirm the system.map and modules paths are in fact valid to
the current running kernel version on the system)

[Fedora (fedora-redhat-bugs)]

kernel-2.6.23.15-137.fc8 has been submitted as an update for Fedora 8

[Frank (frank-redhat-bugs)]

Here's a possible systemtap-based band-aid, until the patched kernels are installed:

stap -g -e 'probe syscall.vmsplice {
   printf("blocking vmsplice (%s) uid %d pid %d exec %s\n", argstr, uid(),
pid(), execname())
   $nr_segs = 0
}'

[Fadi Kaba (fadi-kaba)]

Hi guys,

Just got a question in regards to the above theory, you have mentioned that kernel 2.6.17-2.6.24 is affected whereas a normal user have the ability to login as root with no password and sudo command,so my question here is that I have two version of Kernel on two separate machines 2.6.15-26 and 2.6.16 are these kernel affected as well.

If they are what patch should we follow to stop this from happening

It will be please of some expert answer my query as I am new to Linux and security topics

Thanks in advanced
Fadi

[agt (agt-redhat-bugs)]

@Ryan, make sure you have kernel-PAE-devel installed, and then undo your
Makefile path changes. The modules compile and insmod properly for me. Thanks,
Ola!

[juanino (juanino-redhat-bugs)]

Created attachment 294535
x86_64 panic on ptpach module load

[juanino (juanino-redhat-bugs)]

to clarify, the module from comment#10 panic's on x86_64 for me.

[ryan (ryan-redhat-bugs-1)]

(In reply to comment #13)
> @Ryan, make sure you have kernel-PAE-devel installed, and then undo your
> Makefile path changes. The modules compile and insmod properly for me. Thanks,
> Ola!

Perfect, that did the trick - had not realized there was a specific pae-devel
package.

[Ante Karamatić (ivoks)]

Fadi, no, 2.6.15 isn't affected. I can't test 2.6.16, but it also shouldn't be affected.

[Fadi Kaba (fadi-kaba)]

Thanks Ante,
How did you test kernel 2.6.15 I have a machine here with kernel 2.6.16 and
might test on it

On Feb 11, 2008 5:47 PM, Ante Karamatić <email address hidden> wrote:

> Fadi, no, 2.6.15 isn't affected. I can't test 2.6.16, but it also
> shouldn't be affected.
>
> --
> Local root exploit in kernel 2.6.17 - 2.6.24 (vmsplice)
> https://bugs.launchpad.net/bugs/190587
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Source Package "linux" in Ubuntu: In Progress
> Status in Source Package "linux-source-2.6.17" in Ubuntu: In Progress
> Status in Source Package "linux-source-2.6.20" in Ubuntu: In Progress
> Status in Source Package "linux-source-2.6.22" in Ubuntu: In Progress
> Status in Debian GNU/Linux: Unknown
> Status in Source Package "linux" in Fedora: Unknown
> Status in Gentoo Linux: Unknown
> Status in Mandriva Linux: Unknown
>
> Bug description:
> https://bugs.gentoo.org/show_bug.cgi?id=209460 works on at least Hardy
> 2.6.24-7, Edgy 2.6.17-12, but not on Feisty 2.6.20-16.
>

--
Regards,
Fadi Kaba
<email address hidden>

[Fadi Kaba (fadi-kaba)]

2008/2/11 Fadi Kaba <email address hidden>:

> Thanks Ante,
> How did you test kernel 2.6.15 I have a machine here with kernel 2.6.16and might test on it
>
>
> On Feb 11, 2008 5:47 PM, Ante Karamatić <email address hidden> wrote:
>
> > Fadi, no, 2.6.15 isn't affected. I can't test 2.6.16, but it also
> > shouldn't be affected.
> >
> > --
> > Local root exploit in kernel 2.6.17 - 2.6.24 (vmsplice)
> > https://bugs.launchpad.net/bugs/190587
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
> > Status in Source Package "linux" in Ubuntu: In Progress
> > Status in Source Package "linux-source-2.6.17" in Ubuntu: In Progress
> > Status in Source Package "linux-source-2.6.20" in Ubuntu: In Progress
> > Status in Source Package "linux-source-2.6.22" in Ubuntu: In Progress
> > Status in Debian GNU/Linux: Unknown
> > Status in Source Package "linux" in Fedora: Unknown
> > Status in Gentoo Linux: Unknown
> > Status in Mandriva Linux: Unknown
> >
> > Bug description:
> > https://bugs.gentoo.org/show_bug.cgi?id=209460 works on at least Hardy
> > 2.6.24-7, Edgy 2.6.17-12, but not on Feisty 2.6.20-16.
> >
>
>
>
> --
> Regards,
> Fadi Kaba
> <email address hidden>

--
Regards,
Fadi Kaba
<email address hidden>

[Mathieu Marquer (slasher-fun)]

Temporary fix :

* Download http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c
* Compile it using gcc (so "gcc disable-vmsplice-if-exploitable.c -o rm_exploit") as normal user
* Run it as normal user
--> You are now protected until the next reboot of the system

[Mathieu Marquer (slasher-fun)]

Just some corrections to my previous post :

Line 4 :
* Compile it using gcc (so "gcc disable-vmsplice-if-exploitable.c -o rm_exploit" without the quotes) as normal user
Line 5 :
* Run it as normal user ("./rm_exploit" without the quotes)

[Kees Cook (kees)]

For record, Dapper (2.6.15) is not affected.

Also, CVEs for these issues are:
CVE-2008-0009 (2.6.22+), CVE-2008-0010 (2.6.17+ -- see get_iovec_page_array prior to 2.6.22), CVE-2008-0600 (2.6.17+).

[William Pitcock (nenolod)]

Hi,

This doesn't work, because it still creates a DoS condition when it
alters your memory map.

On Mon, 2008-02-11 at 07:08 +0000, slasher-fun wrote:
> Temporary fix :
>
> * Download http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c
> * Compile it using gcc (so "gcc disable-vmsplice-if-exploitable.c -o rm_exploit") as normal user
> * Run it as normal user
> --> You are now protected until the next reboot of the system
>

[Kees Cook (kees)]

Fixes for CVE-2008-0009, CVE-2008-0010:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8811930dc74a503415b35c4a79d14fb0b408a361

Fixes for CVE-2008-0600:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44

[thoger (thoger-redhat-bugs)]

*** Bug 432308 has been marked as a duplicate of this bug. ***

[thoger (thoger-redhat-bugs)]

*** Bug 432288 has been marked as a duplicate of this bug. ***

[artms (artms-redhat-bugs)]

On kernel-2.6.18-53.1.6.el5xen (x86_64) this exploit makes kernel panic.

[mattdm (mattdm-redhat-bugs)]

Not to detract from the real work, but can someone describe the
access-restricted bugs marked as blocking this? (Bug #432252, Bug #432253). Thanks.

[mbooth (mbooth-redhat-bugs)]

These are simply tracking bugs for specific affected products.

[Jan M. (fijam7)]

CVE-2008-0600 fixed in 2.6.22.18 [1,2]

[1] http://lkml.org/lkml/2008/2/11/27
[2] http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commitdiff;h=af395d8632d0524be27d8774a1607e68bdb4dd7f

[Tom (tom-redhat-bugs)]

The stap command doesn't work on FC7, latest kernel (i.e. without the fix):
# uname -a
Linux host 2.6.23.14-64.fc7 #1 SMP Sun Jan 20 22:20:19 EST 2008 x86_64 x86_64
x86_64 GNU/Linux
# stap -v -g -e 'probe syscall.vmsplice {
   printf("blocking vmsplice (%s) uid %d pid %d exec %s\n", argstr, uid(),
pid(), execname())
   $nr_segs = 0
}'
Pass 1: parsed user script and 54 library script(s) in 210usr/0sys/226real ms.
semantic error: probe point mismatch at position 1 (alternatives: accept access
acct add_key adjtimex alarm arch_prctl bdflush bind brk capget capset chdir
chmod chown chown16 chroot clock_getres clock_gettime clock_nanosleep
clock_settime close compat_getitimer compat_nanosleep compat_setitimer
compat_utime connect creat delete_module dup dup2 epoll_create epoll_ctl
epoll_wait execve exit exit_group fadvise64 fadvise64_64 fchdir fchmod fchown
fchown16 fcntl fdatasync fgetxattr flistxattr flock fork fremovexattr fsetxattr
fstat fstatfs fstatfs64 fsync ftruncate ftruncate64 futex get_mempolicy getcwd
getdents getdents64 getegid getegid16 geteuid geteuid16 getgid getgid16
getgroups getgroups16 gethostname getitimer getpeername getpgid getpgrp getpid
getppid getpriority getresgid getresgid16 getresuid getresuid16 getrlimit
getrusage getsid getsockname getsockopt gettid gettimeofday getuid getuid16
getxattr init_module io_cancel io_destroy io_getevents io_setup io_submit ioctl
ioperm iopl ioprio_get ioprio_set kexec_load keyctl kill lchown lchown16
lgetxattr link listen listxattr llistxattr llseek lookup_dcookie lremovexattr
lseek lsetxattr lstat madvise mbind mincore mkdir mkdirat mknod mlock mlockall
mmap mmap2 modify_ldt mount mprotect mq_getsetattr mq_notify mq_open
mq_timedreceive mq_timedsend mq_unlink mremap msgctl msgget msgrcv msgsnd msync
munlock munlockall munmap nanosleep nfsservctl ni_syscall nice old_getrlimit
open pause personality pipe pivot_root poll prctl pread64 ptrace pwrite64
quotactl read readahead readlink readv reboot recv recvfrom recvmsg
remap_file_pages removexattr rename request_key restart_syscall rmdir
rt_sigaction rt_sigaction32 rt_sigpending rt_sigprocmask rt_sigqueueinfo
rt_sigreturn rt_sigsuspend rt_sigtimedwait sched_get_priority_max
sched_get_priority_min sched_getaffinity sched_getparam sched_getscheduler
sched_rr_get_interval sched_setaffinity sched_yield select semctl semget semop
semtimedop send sendfile sendmsg sendto set_mempolicy set_tid_address
setdomainname setfsgid setfsgid16 setfsuid setfsuid16 setgid setgid16 setgroups
setgroups16 sethostname setitimer setpgid setpriority setregid setregid16
setresgid setresgid16 setresuid setresuid16 setreuid setreuid16 setrlimit setsid
setsockopt settimeofday settimeofday32 setuid setuid16 setxattr sgetmask shmctl
shmdt shmget shutdown sigaltstack signal sigpending sigprocmask socket
socketpair ssetmask stat statfs statfs64 stime swapoff swapon symlink sync
sysctl sysfs sysinfo syslog tgkill time timer_create timer_delete
timer_getoverrun timer_gettime timer_settime times tkill truncate tux umask
umount uname unlink uselib ustat ustat32 utime utimes vhangup wait4 waitid write
writev) while resolving probe point syscall.vmsplice
Pass 2: analyzed script: 0 p...

[Mark (mark-redhat-bugs)]

Note that to use systemtap you would need to have installed the kernel debuginfo
packages for your kernel. See
http://www.redhat.com/magazine/011sep05/features/systemtap/ for details on how
to set up systemtap.

[mjc (mjc-redhat-bugs)]

In reply to comment #20; there are some bugs in the exploit which means that it
doesn't work directly on x86_64 machines, although it can be modified to do so.

[Frank (frank-redhat-bugs)]

(In reply to comment #13)
> The stap command doesn't work on FC7, latest kernel (i.e. without the fix):
> # uname -a
> Linux host 2.6.23.14-64.fc7 #1 SMP Sun Jan 20 22:20:19 EST 2008 x86_64 x86_64
> x86_64 GNU/Linux
> Pass 1: parsed user script and 54 library script(s) in 210usr/0sys/226real ms.
> semantic error: probe point mismatch at position 1 [...]

Some older systemtap versions lack the "syscall.vmsplice" alias.
I'm sorry I didn't check, but the one in fedora7 (0.5.13-1.fc7)
misses it too. If you add the following clause to your script,
(and if other prerequisites are present), it should work:

probe syscall.vmsplice = kernel.function("sys_vmsplice") ? {
        name = "vmsplice"
        argstr = sprintf("%d, %p, %d, 0x%x", $fd, $iov, $nr_segs, $flags)
}

[russell (russell-redhat-bugs-1)]

I can confirm the sample exploit will segfault on athlon on a bare system (would
likely be patchable), but will work as supplied on a XenU.

Segfault: Linux xxxx 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 EST 2007 i686
athlon i386 GNU/Linux

Exploitable: Linux xxxx 2.6.21-2952.fc8xen #1 SMP Mon Nov 19 07:06:55 EST 2007
i686 athlon i386 GNU/Linux

[mpeters (mpeters-redhat-bugs)]

The exploit worked for me w/o a segfault on i386 Duron (
kernel-2.6.18-53.1.6.el5 ) and x86_64 Athlon X2 (5200+ - same kernel but x86_64
install)

on i386 it did not consistently work, and I'm guessing related, the machine had
to be rebooted as it kept dropping ssh connections after the exploit was run.

Both boxes are CentOS (opposed to RHEL) if it matters.

[nabil2199 (nabil2199-gmail)]

confirmed in gutsy 2.6.22-14-generic

[Matt (matt-redhat-bugs)]

Can you please supply a complete systemtap script for versions older than FC7?

[Tim Gardner (timg-tpi)]

Kees - from what I can tell CVE-2008-0009 and CVE-2008-0010 affect only 2.6.23 through 2.6.24.1. CVE-2008-0600 affects 2.6.17 through 2.6.24.1.

Greg k-h:
"It has been given CVE-2008-0600 to address this issue (09 and 10 only
affect .23 and .24 kernels, and have been fixed.)"

We'll get all 3 CVEs fixed in the 2.6.24.2 stable tree, upon which Hardy 2.6.24-7.13 will be based.

I am packaging fixes for Edgy/Feisty/Gusty .

[donhoover (donhoover-redhat-bugs)]

I verified it working on RHEL5 and RHEL 5.1 32bit boxes using both the older and
newer -53 kernels in both single and SMP installs.

The exploit does seem to make the systems unstable and they have crashed after
running a little longer after someone uses this exploit.

[Boglizk (boglizk)]

Seems to fail on this part:

        if (!uid || !gid)
                die("!@#$", 0);

-------

boglizk@thebox:~$ gcc linux_vmsplice.c
boglizk@thebox:~$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[-] !@#$
boglizk@thebox:~$ uname -a
Linux thebox 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux

[erek (erek-redhat-bugs)]

I've compiled an interim RPM for my internal use, as I considered this safer
than the kernel module which has caused panics. It's the same as 2.6.18-53
Centos, but with the upstream kernel patch applied. Obviously your mileage may vary.

http://erek.blumenthals.com/blog/2008/02/11/rhel-5-centos-5-kernel-rpms-patched-against-vmsplice-local-root-exploit/

[erek (erek-redhat-bugs)]

That's against 2.6.53.1.6, not 2.6.53 as I said previously.

[Matt (matt-redhat-bugs)]

To answer my own question, this works:

stap -v -g -e 'probe syscall.vmsplice = kernel.function("sys_vmsplice") ? {
        name = "vmsplice"
        argstr = sprintf("%d, %p, %d, 0x%x", $fd, $iov, $nr_segs, $flags)
}

probe syscall.vmsplice {
   printf("blocking vmsplice (%s) uid %d pid %d exec %s\n", argstr, uid(),
pid(), execname())
   $nr_segs = 0
}'

[Jason (jason-redhat-bugs)]

There is also a kernel module fix that catches vmsplice calls:
http://home.powertech.no/oystein/ptpatch2008/

Makefile and source code worked as is for my 2.6.23.14-115.fc8 x86_64 kernel.
After insmod, execution of the exploit fails:

$ sudo insmod ptpatch2008.ko
$ dmesg | tail -3
ptpatch2008: init, (c) 2008 <email address hidden>
ptpatch2008: syscalls ffffffff81270780
hooked sys_vmsplice
$ ./exploit_test
[...]
[-] vmsplice: Invalid argument
$ dmesg | tail -4
ptpatch2008: init, (c) 2008 <email address hidden>
ptpatch2008: syscalls ffffffff81270780
hooked sys_vmsplice
ptpatch2008: possible EXPLOIT attempt by uid 500.

[James (james-redhat-bugs)]

I've grabbed the koji build, any word on when the fix will be pushed to
updates[-testing]?

[Matt (matt-redhat-bugs)]

(In reply to comment #18)
> There is also a kernel module fix that catches vmsplice calls:
> http://home.powertech.no/oystein/ptpatch2008/
>
> Makefile and source code worked as is for my 2.6.23.14-115.fc8 x86_64 kernel.
> After insmod, execution of the exploit fails:
>
> $ sudo insmod ptpatch2008.ko
> $ dmesg | tail -3
> ptpatch2008: init, (c) 2008 <email address hidden>
> ptpatch2008: syscalls ffffffff81270780
> hooked sys_vmsplice
> $ ./exploit_test
> [...]
> [-] vmsplice: Invalid argument
> $ dmesg | tail -4
> ptpatch2008: init, (c) 2008 <email address hidden>
> ptpatch2008: syscalls ffffffff81270780
> hooked sys_vmsplice
> ptpatch2008: possible EXPLOIT attempt by uid 500.

This is perfect for our needs. Can anyone confirm that this patch is safe? I'm
afraid my code reviewing days are behind me. :)

-Matt

[jakub (jakub-redhat-bugs-1)]

Hey boys, Debian has already fixed this, where is Red Hat? Thank you very much.

[mattdm (mattdm-redhat-bugs)]

> Hey boys, Debian has already fixed this, where is Red Hat? Thank you very much.

Doing quality control on the produced updates, presumably.

[admin (admin-redhat-bugs)]

RHAT had it fixed on 2/8 see the .79 kernel in:

http://people.redhat.com/dzickus/el5/79.el5

I tested it on i686 and was unable to use millw0rm exploit 5092 or 5093. it also
fixes another NFS issue from bug 431092.

[®om (rom1v)]

Why priority is "high" but no "critical"?
Is there a higher criticity than a root exploit in 3 seconds?

[amyagi (amyagi-redhat-bugs)]

(In reply to comment #31)
> RHAT had it fixed on 2/8 see the .79 kernel in:
>
> http://people.redhat.com/dzickus/el5/79.el5
>
> I tested it on i686 and was unable to use millw0rm exploit 5092 or 5093. it also
> fixes another NFS issue from bug 431092.

However, keep in mind that it is a TEST kernel. The .78 kernel I tested and
confirmed about the nfs fix is UNstable and some people are experiencing system
instability / crashes.

[mjc (mjc-redhat-bugs)]

The Red Hat Security Response Team is working with engineering and QA on the
updated packages for Red Hat Enterprise Linux 5. We'll release them immediately
to the Red Hat Network once they pass our testing and QA processes.

(Updated Fedora kernels are currently being pushed live and will be available soon)

[Jan M. (fijam7)]

Yes, a remote root exploit.

[Tom Lippincott (tom-cs)]

Hi,
I was wondering how others are dealing with this, beyond the runtime patch on bootup. It seems like a tossup between grabbing/patching kernel source and waiting for the security update, does anyone know a rough eta on a safe gutsy kernel package? Thanks for the help, this is new territory for me.

[Mark (mark-redhat-bugs)]

FYI ptpatch2008 under fc6 yields this:

ptpatch2008: init, (c) 2008 <email address hidden>
ptpatch2008: no sct, bailing out

[yaztromo (tromo)]

Tom, the present hotfix is dangerous. See http://lists.debian.org/debian-kernel/2008/02/msg00387.html

[Ken Simon (ninkendo)]

Indeed, I ran the hotfix on my desktop last night (gutsy with latest
updates) and as soon as it finished, running programs began to crash.
I wasn't able to see any error messages to dmesg, but the system was
unstable enough that I had to reboot it. I would *not* recommend
running the hotfix.

[Jan M. (fijam7)]

Duh. What about using the patch from the upstream? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/190587/comments/26

[Michael Trunner (trunneml)]

@Boglizk: Not run it as root.

[Tom (tom-redhat-bugs)]

The kernel module stops the exploit on my latest FC7 2.6.23.14-64.fc8 x86_64
kernel.
The kernel-debuginfo etc. packages are hundreds and hundreds of meg, so a few
K of kernel module is a much better interim fix, imvho.

[Phil (phil-redhat-bugs)]

On an unpatched 2.6.23, I got this:

Feb 11 20:56:52 holly kernel: ptpatch2008: init, (c) 2008 <email address hidden>
Feb 11 20:56:52 holly kernel: ptpatch2008: syscalls c0622540
Feb 11 20:56:52 holly kernel: ptpatch2008: syscall table might be readonly
Feb 11 20:56:52 holly kernel: hooked sys_vmsplice

I ran a quick test of the exploit code, which failed with a "[-] wtf" error,
then a few seconds later the message log filled up with this:

Feb 11 20:57:54 holly kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x0
Feb 11 20:57:54 holly kernel: ata1.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00
tag 0 cdb 0x0 data 0
Feb 11 20:57:54 holly kernel: res 51/04:00:00:4f:c2/00:00:00:00:00/00
Emask 0x1 (device error)
Feb 11 20:57:54 holly kernel: ata1.00: Host Protected Area detected:
Feb 11 20:57:54 holly kernel: current size: 321670847 sectors
Feb 11 20:57:54 holly kernel: native size: 321672960 sectors
Feb 11 20:57:54 holly kernel: ata1.00: Host Protected Area detected:
Feb 11 20:57:54 holly kernel: current size: 321670847 sectors
Feb 11 20:57:54 holly kernel: native size: 321672960 sectors
Feb 11 20:57:54 holly kernel: ata1.00: configured for UDMA/133
Feb 11 20:57:54 holly kernel: ata1: EH complete
Feb 11 20:57:54 holly kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x0
Feb 11 20:57:54 holly kernel: ata1.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 t
ag 0 cdb 0x0 data 0
Feb 11 21:02:08 holly kernel: res 51/04:00:00:4f:c2/00:00:00:00:00/00 E
mask 0x1 (device error)
Feb 11 21:02:08 holly kernel: ata1.00: Host Protected Area detected:
Feb 11 21:02:08 holly kernel: current size: 321670847 sectors
Feb 11 21:02:08 holly kernel: native size: 321672960 sectors
Feb 11 21:02:08 holly kernel: ata1.00: Host Protected Area detected:
Feb 11 21:02:08 holly kernel: current size: 321670847 sectors
Feb 11 21:02:08 holly kernel: native size: 321672960 sectors
Feb 11 21:02:08 holly kernel: ata1.00: configured for UDMA/133
Feb 11 21:02:08 holly kernel: ata1: EH complete
Feb 11 21:02:08 holly kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 act
ion 0x0
Feb 11 21:02:08 holly kernel: ata1.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 t
ag 0 cdb 0x0 data 0
Feb 11 21:02:08 holly kernel: res 51/04:00:00:4f:c2/00:00:00:00:00/00 E
mask 0x1 (device error)
Feb 11 21:02:08 holly smartd[4692]: smartd version 5.36 [i686-redhat-linux-gnu]
Copyright (C) 2002-6 Bruce Allen
Feb 11 21:02:08 holly kernel: ata1.00: Host Protected Area detected:
Feb 11 21:02:08 holly smartd[4692]: Home page is http://smartmontools.sourceforg
e.net/
Feb 11 21:02:08 holly kernel: current size: 321670847 sectors

And the machine promptly panicked.

[Don (don-redhat-bugs)]

FYI..this ptpatch2008 kernel module compiles fine, but causes a GPF/crash on a
AMD64 box when insmod is attempted.

[donhoover (donhoover-redhat-bugs)]

The system tap does not seem to catch/deny every run of the exploit in my
testing. They all seem to get logged, but many of them still get a root prompt.

The system is also still unstable, and either the exploit running multiple times
or the system tap eventually cause a kernel crash.

[Fedora (fedora-redhat-bugs)]

kernel-2.6.23.15-137.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.

[Tim Gardner (timg-tpi)]

The fix for this vulnerability is in the 2.6.24.2 tree against which Hardy was recently updated and is in the process of being packaged for upload.

[jkmoseley (jkmoseley-redhat-bugs)]

(In reply to comment #16)
> (In reply to comment #13)
> > @Ryan, make sure you have kernel-PAE-devel installed, and then undo your
> > Makefile path changes. The modules compile and insmod properly for me.
Thanks,
> > Ola!
> Perfect, that did the trick - had not realized there was a specific pae-devel
> package.

I was able to successfully compile the module on a FC5 system, but when trying
to add via insmod, I get:

insmod: error inserting 'ptpatch2008.ko': -1 Operation not permitted

[cybaix (cybaix)]

What about Gutsy, any update when the fix will be released?

[fche (fche-redhat-bugs)]

(In reply to comment #36)
> The system tap does not seem to catch/deny every run of the exploit in my
> testing. They all seem to get logged, but many of them still get a root prompt.

The systemtap script proposed in comment #35 is a poor choice, so is
now hidden in order to avoid misleading the public. It interfered
with multiple functions in fs/splice.c, and did not actually block
the vmsplice attempt but rather just attempt to log and punish it.

If you have the prerequisites for this tool though, try the simpler
script listed in bug #432229 comment #17.

[Russell (russell-redhat-bugs)]

Will kernel-xen packages also be created?

[Yuri (ycsapo)]

Contrary to what I've been reading, I can confirm this on feisty, at least with AMD processor:

ycsapo@pie:~$ grep "model name" /proc/cpuinfo
model name : Dual-Core AMD Opteron(tm) Processor 2218
model name : Dual-Core AMD Opteron(tm) Processor 2218
model name : Dual-Core AMD Opteron(tm) Processor 2218
model name : Dual-Core AMD Opteron(tm) Processor 2218
ycsapo@pie:~$ uname -a
Linux pie 2.6.20-16-generic #2 SMP Thu Jan 31 22:39:18 UTC 2008 x86_64 GNU/Linux
ycsapo@pie:~$ ./exploit
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x100000000000 .. 0x100000001000
[+] page: 0x100000000000
[+] page: 0x100000000038
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4038
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x2ac0a9f0d000 .. 0x2ac0a9f3f000
[+] root
root@pie:~# whoami
root
root@pie:~#

I also confirm the suggested hotfix (disable-vmsplice-if-exploitable.c) works:

ycsapo@pie:~$ cc disable-vmsplice-if-exploitable.c
ycsapo@pie:~$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x100000000000 .. 0x100000001000
[+] page: 0x100000000000
[+] page: 0x100000000038
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4038
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x2acad5163000 .. 0x2acad5195000
[+] root
Exploit gone!
ycsapo@pie:~$ ./exploit
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x100000000000 .. 0x100000001000
[+] page: 0x100000000000
[+] page: 0x100000000038
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4038
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x2b010025b000 .. 0x2b010028d000
[-] vmsplice
ycsapo@pie:~$ whoami
ycsapo

[tonfa (bboissin)]

On Tue, Feb 12, 2008 at 03:18:36AM -0000, Yuri wrote:
> Contrary to what I've been reading, I can confirm this on feisty, at
> least with AMD processor:

of course feisty is exploitable it works for 2.6.17-2.6.24.1 (and see
the summary of the bug, 2.6.20 is mentionned).

--
:wq

[verb3k (verb3k)]

I also confirm this in Hardy.

[®om (rom1v)]

When will the fixe be upgraded in repositories (gutsy)?

[ismail (ismailh)]

The exploit does not seem to work on feisty:
$ gcc vmsplice.c -o vmsp
$ ./vmsp
-----------------------------------
 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: 0xb7e20000 .. 0xb7e52000
Segmentation fault (core dumped)

But the exploit works on Gusty and the fix in http://home.powertech.no/oystein/ptpatch2008/ptpatch2008.c seems to work:

Remember that the Makefile (http://home.powertech.no/oystein/ptpatch2008/Makefile) has to be downloaded also. After you run make all, there will be a kernel module called ptpatch2008.ko in the same directory. Insert the module into the kernel:
#insmod ptpatch2008.ko

This will prevent the privilege escalation as long as the machine is not rebooted. You can also insert the module at startup in the event the machine is rebooted. This has worked for me so far, until we get an official fix in the repository.

[mjc (mjc-redhat-bugs)]

Just a quick status update; we have updated kernel packages released for Fedora
(see linked bugs) and are finishing up the QA process for Red Hat Enterprise
Linux 5. We expect this to be completed shortly (pending successful completion
of testing). This will be RHSA-2008:0129.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux-source-2.6.22 - 2.6.22-14.52

---------------
linux-source-2.6.22 (2.6.22-14.52) gutsy-security; urgency=low

  [Tim Gardner]

  * splice: fix user pointer access in get_iovec_page_array()
    (CVE-2008-0600)
    - LP: #190587

 -- Tim Gardner <email address hidden> Mon, 11 Feb 2008 10:01:17 -0700

[mjc (mjc-redhat-bugs)]

This vulnerability, CVE-2008-0600, did not affect Red Hat Enterprise Linux 2.1,
3, or 4. Updated packages to correct this vulnerability are now available for
Red Hat Enterprise Linux along with our advisory at the URL:

https://rhn.redhat.com/errata/RHSA-2008-0129.html

Since all Red Hat and Fedora products are not updated, closing the bug.

[Eduardo (eduardo-redhat-bugs)]

(In reply to comment #26)
> Will kernel-xen packages also be created?
>

bug #432517 was created to track kernel-xen packages.

[Jamie Strandboge (jdstrand)]

http://www.ubuntu.com/usn/usn-577-1

[Adna rim (adnarim)]

Thanks for the people who helped with fixing this bug! But I have a question: why had fedora and debian already released a updated kernel yesterday to fix this problem and why ubuntu just now with many hours delay to the other great distributions? Did you have any problem apling the debian-patch to the ubuntu kernel?

greets

[magilus (magilus)]

Fedora and Debian do not support as many releases as Ubuntu and thus the time consumption to package and test if any regressions appear is longer than for others.

But honestly, the time frame from the patches being published to having security updates in Ubuntu was ~ 48 hours, which is good in my opinion. Just compare it to once a month (granted that for such critical bugs MS would probably do an exception)

[Adna rim (adnarim)]

Thanks for the answer. Of course you are right, that 48h isn't that long for a just local exploit. And of course any comparison with MS is surely won by ubuntu :) I was just wondering why debian's updated kernel was so many hours before ubuntu's released. The places to patch the kernel-source should be exactly the same in both.

>> thus the time consumption to package and test if
>> any regressions appear is longer than for others.
Means that there is an all or nothing policy? So even if the i386-patch would have been created and tested it hadn't been released before the patches for generic- and 64bit-kernels had been created and released?

greets

[Michael B. Trausch (mtrausch)]

On Tue, 2008-02-12 at 18:50 +0000, Martin Jürgens wrote:
> But honestly, the time frame from the patches being published to
> having security updates in Ubuntu was ~ 48 hours, which is good in my
> opinion. Just compare it to once a month (granted that for such
> critical bugs MS would probably do an exception)

Eh, not necessarily. Microsoft took 18 months to fix a critical remote
code execution exploit in their TCP/IP stack:

http://www.microsoft.com/technet/security/Bulletin/MS06-032.mspx
http://www.microsoft.com/technet/security/bulletin/ms08-001.mspx

Ubuntu has done most excellently in getting this patched as soon as it
did. Microsoft likes to sling mud at projects like Ubuntu for the
number of open bugs that there are on the public bug trackers, but there
is no point to it---it's pure FUD. We can't see what bugs they have in
their internal trackers, and there are probably more of them (and far
worse) than we have in ours. What we can see is that they take a long
time to close critical security flaws in their operating system, and
that is one of the many reasons there are to use Ubuntu. Let's not
forget that. 48 hours? That's hardly nothing. Even 96 is nothing.

 --- Mike

--
Michael B. Trausch <email address hidden>
home: 404-592-5746, 1 www.trausch.us
cell: 678-522-7934 im: <email address hidden>, jabber
Ubuntu Unofficial Backports Project: http://backports.trausch.us/

[Michael B. Trausch (mtrausch)]

On Tue, 2008-02-12 at 19:11 +0000, Adna rim wrote:
> Means that there is an all or nothing policy? So even if the
> i386-patch would have been created and tested it hadn't been released
> before the patches for generic- and 64bit-kernels had been created and
> released?

IIRC, the kernels are all put into a build queue at the same time.
There is testing before it's sent off to be built by the machines that
build for the repository. This would not be unlike the way PPA works.

 --- Mike

--
Michael B. Trausch <email address hidden>
home: 404-592-5746, 1 www.trausch.us
cell: 678-522-7934 im: <email address hidden>, jabber
Ubuntu Unofficial Backports Project: http://backports.trausch.us/

[Michael (m-gruys)]

My compliments for the fast response for this exploit. I have just one question left about this exploit: I have just executed the proof-of-concept code (http://www.milw0rm.com/exploits/5092) again with the updated kernel. Is there no memory corruption at all with this new kernel version?
Or should I reboot my pc after running the proof-of-concept) just for sure?
Thanks.

[Kyle Lee (shrednine)]

It seems to me that as the number of Ubuntu's supported releases continues to grow, it's going to get harder for the development team to verify bugs and get fixes out for all the supported versions. Aside from reporting bugs and exploits, how can users with programming experience assist with this?

[Chris Coulson (chrisccoulson)]

I think that the number of supported releases should stay fairly static as support for older releases is dropped. For example, Edgy is only supported on the desktop until April, when Hardy is released.

[Kyle M Weller (kylew)]

Running Hardy Heron, Latest updates:
kyle@ubuntu:~$ uname -a
Linux ubuntu 2.6.24-7-generic #1 SMP Thu Feb 7 01:29:58 UTC 2008 i686 GNU/Linux
kyle@ubuntu:~$ whoami
kyle
kyle@ubuntu:~$ ./local
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] addr: 0xc011d7e0
[+] root
root@ubuntu:~# whoami
root
root@ubuntu:~#

[Jamie Strandboge (jdstrand)]

linux (2.6.24-8.13) hardy; urgency=low

  [Soren Hansen]

  * Add missing iscsi modules to kernel udebs

  [Stefan Bader]

  * Lower message level for PCI memory and I/O allocation.

  [Tim Gardner]

  * Enabled IP_ADVANCED_ROUTER and IP_MULTIPLE_TABLES in sparc, hppa
    - LP: #189560
  * Compile RealTek 8139 using PIO method.
    - LP: #90271
  * Add WD WD800ADFS NCQ horkage quirk support.
    - LP: #147858

  [Upstream Kernel Changes]

  * Introduce WEXT scan capabilities
  * DVB: cx23885: add missing subsystem ID for Hauppauge HVR1800 Retail
  * slab: fix bootstrap on memoryless node
  * vm audit: add VM_DONTEXPAND to mmap for drivers that need it
    (CVE-2008-0007)
  * USB: keyspan: Fix oops
  * usb gadget: fix fsl_usb2_udc potential OOPS
  * USB: CP2101 New Device IDs
  * USB: add support for 4348:5523 WinChipHead USB->RS 232 adapter
  * USB: Sierra - Add support for Aircard 881U
  * USB: Adding YC Cable USB Serial device to pl2303
  * USB: sierra driver - add devices
  * USB: ftdi_sio - enabling multiple ELV devices, adding EM1010PC
  * USB: ftdi-sio: Patch to add vendor/device id for ATK_16IC CCD
  * USB: sierra: add support for Onda H600/Zte MF330 datacard to USB Driver
    for Sierra Wireless
  * USB: remove duplicate entry in Option driver and Pl2303 driver for
    Huawei modem
  * USB: pl2303: add support for RATOC REX-USB60F
  * USB: ftdi driver - add support for optical probe device
  * USB: use GFP_NOIO in reset path
  * USB: Variant of the Dell Wireless 5520 driver
  * USB: storage: Add unusual_dev for HP r707
  * USB: fix usbtest halt check on big endian systems
  * USB: handle idVendor of 0x0000
  * forcedeth: mac address mcp77/79
  * lockdep: annotate epoll
  * sys_remap_file_pages: fix ->vm_file accounting
  * PCI: Fix fakephp deadlock
  * ACPI: update ACPI blacklist
  * x86: restore correct module name for apm
  * sky2: restore multicast addresses after recovery
  * sky2: fix for WOL on some devices
  * b43: Fix suspend/resume
  * b43: Drop packets we are not able to encrypt
  * b43: Fix dma-slot resource leakage
  * b43legacy: fix PIO crash
  * b43legacy: fix suspend/resume
  * b43legacy: drop packets we are not able to encrypt
  * b43legacy: fix DMA slot resource leakage
  * selinux: fix labeling of /proc/net inodes
  * b43: Reject new firmware early
  * sched: let +nice tasks have smaller impact
  * sched: fix high wake up latencies with FAIR_USER_SCHED
  * fix writev regression: pan hanging unkillable and un-straceable
  * Driver core: Revert "Fix Firmware class name collision"
  * drm: the drm really should call pci_set_master..
  * splice: missing user pointer access verification (CVE-2008-0009/10)
  * Linux 2.6.24.1
  * splice: fix user pointer access in get_iovec_page_array()
  * Linux 2.6.24.2

 -- Tim Gardner < <email address hidden>> Thu, 07 Feb 2008 06:50:13 -0700

[lwang (lwang-redhat-bugs)]

*** Bug 432319 has been marked as a duplicate of this bug. ***

[Chuck (chuck-redhat-bugs)]

*** Bug 441414 has been marked as a duplicate of this bug. ***

[Jamie Strandboge (jdstrand)]

Per Gentoo, it's now fixed in all releases.

[Anderson (amg1127)]

No, I don't want to join at LinkedIn!

[ucelsanicin (ucelsanicin-linux-kernel-bugs)]

Possibly similar to 23220 however on 64-bit recent Debian sid with
trivial code I see : https://www.webb-dev.co.uk/category/crypto/

mimas$
mimas$ uname -a http://www.compilatori.com/category/services/
Linux mimas 5.10.0-6-sparc64 #1 Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux
mimas$
http://www.acpirateradio.co.uk/category/services/
mimas$
mimas$ /usr/bin/gcc --version http://www.logoarts.co.uk/category/services/
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO http://www.slipstone.co.uk/category/services/
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

mimas$ http://embermanchester.uk/category/services/

mimas$
mimas$ cat -n foo.c http://connstr.net/category/services/
     1
     2 #include <stdio.h>
     3 #include <stdlib.h>
     4 http://joerg.li/category/services/
     5 int main(int argc, char **argv)
     6 {
     7 int a = 1;
     8 http://www.jopspeech.com/category/services/
     9 printf("a = %i\n", a);
    10 http://www.wearelondonmade.com/category/services/
    11 printf("&a = %p\n", &a);
    12
    13 return EXIT_SUCCESS;
    14 https://waytowhatsnext.com/category/crypto/
    15 }
    16
mimas$ http://www.iu-bloomington.com/category/crypto/

mimas$
mimas$ /usr/bin/gcc -std=iso9899:1999 -pedantic -pedantic-errors -fno-builtin https://komiya-dental.com/category/crypto/ -g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso -o foo foo.c
mimas$ http://www-look-4.com/category/services/

mimas$
mimas$ TERM=dumb LC_ALL=C /usr/bin/gdb ./foo
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git