[NEWS] Kernel security exploits: Upgrade ASAP

[dberkholz]

This forums thread is for discussion of the www.gentoo.org posting, "Kernel security exploits: Upgrade ASAP." Post your comments and suggestions here.

Two major security flaws in the Linux kernel were reported last weekend. Both flaws have the same impact (root access for local users) and both exist within the vmsplice() system call, which was added to the kernel in 2.6.17. There is no configuration option to exclude vmsplice() so everyone is vulnerable.

One of the security issues existed for the entire lifetime of vmsplice(), so any kernel version from 2.6.17 onwards is vulnerable. This was fixed in 2.6.24.2, 2.6.23.16 and 2.6.22.18. It has been assigned the vulnerability identifier of CVE-2008-0600.

The other security issue first appeared in 2.6.23. It was fixed in 2.6.23.15 and 2.6.24.1. This vulnerability has been assigned CVE-2008-0009 and CVE-2008-0010.

gentoo-sources-2.6.23-r8 and gentoo-sources-2.6.24-r2 were added to the tree Monday and include fixes for both issues. Install the latest gentoo-sources as quickly as possible.

...
(more on gentoo.org)

[Kuja]

so hardened is affected too then?
or not?

edit: ignore that post, didn't saw that hardened was bumped on monday too, so it seems to be affected then

[hoffie]

so hardened is affected too then?
or not?

Hardened kernels are vulnerable as well, but depending on the configuration there is a chance that it is not exploitable.

See https://bugs.gentoo.org/show_bug.cgi?id=209460#c14, https://bugs.gentoo.org/show_bug.cgi?id=209460#c35 and https://bugs.gentoo.org/show_bug.cgi?id=207393

[MrCanis]

This forums thread is for discussion of the www.gentoo.org posting, "Kernel security exploits: Upgrade ASAP." Post your comments and suggestions here.

Two major security flaws in the Linux kernel were reported last weekend. Both flaws have the same impact (root access for local users) and both exist within the vmsplice() system call, which was added to the kernel in 2.6.17. There is no configuration option to exclude vmsplice() so everyone is vulnerable.

One of the security issues existed for the entire lifetime of vmsplice(), so any kernel version from 2.6.17 onwards is vulnerable. This was fixed in 2.6.24.2, 2.6.23.16 and 2.6.22.18. It has been assigned the vulnerability identifier of CVE-2008-0600.

The other security issue first appeared in 2.6.23. It was fixed in 2.6.23.15 and 2.6.24.1. This vulnerability has been assigned CVE-2008-0009 and CVE-2008-0010.

gentoo-sources-2.6.23-r8 and gentoo-sources-2.6.24-r2 were added to the tree Monday and include fixes for both issues. Install the latest gentoo-sources as quickly as possible.

...
(more on gentoo.org)

Hello,
gentoo-sources-2.6.24-r2 are masked:

Code: Select all

emerge -av '>=gentoo-sources-2.6.24-r2'

These are the packages that would be merged, in order:

Calculating dependencies |
!!! All ebuilds that could satisfy ">=gentoo-sources-2.6.24-r2" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-kernel/gentoo-sources-2.6.24-r2 (masked by: ~x86 keyword)

For more information, see MASKED PACKAGES section in the emerge man page or 
refer to the Gentoo Handbook.

Is that version stable and someone has forgotten to unmask that package? Or is a mistake in the announcement (on www.gentoo.org).

Thanks in advance.

PS: I know how to unmask packages, but I don't want emerge a unstable kernel.

[hoffie]

Is that version stable and someone has forgotten to unmask that package? Or is a mistake in the announcement (on www.gentoo.org).

The announcement was inaccurate and has been updated by dberkholz by now. So, =gentoo-sources-2.6.23-r8 is the way to go on a stable system.

[MrCanis]

Is that version stable and someone has forgotten to unmask that package? Or is a mistake in the announcement (on www.gentoo.org).

The announcement was inaccurate and has been updated by dberkholz by now. So, =gentoo-sources-2.6.23-r8 is the way to go on a stable system.

Hello,
thanks for your quick response.

I use =gentoo-sources-2.6.23-r8, therefore I'm on the right site.

[GenKreton]

this is a local exploit only, correct?

[tokj]

this is a local exploit only, correct?

Yes, correct.

[dberkholz]

this is a local exploit only, correct?

Yes, correct.

Yes, but be careful. Someone could exploit a vulnerability in a service that gets them local user-only privileges, and combine that with this in a two-step remote root. It's happened to us before.

[sgao]

What about xen-sources-2.6.20-r6 and xen-sources-2.6.18-r8? Is there any need to patch xen-sources kernels?

Simon

[MannyNix]

Thanks, good job!

[SDenis]

Code: Select all

Linux localhost 2.6.20-xen-r6
~ $ ./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: 0xb7d95000 .. 0xb7dc7000
Segmentation fault

One question - why another Ubuntu, Debian, SuSe just patch kernel, but Gentoo-users need recomlile\reinstall sources?

[mark_alec]

One question - why another Ubuntu, Debian, SuSe just patch kernel, but Gentoo-users need recomlile\reinstall sources?

Because those distributions provide an already compiled kernel.

[steveL]

See [topic=659999]this thread[/topic] for more info.

[kostja]

Hello!

Anybody knows, which tuxonice sources are allready patched?

Konstantin

[ma-ne]

What about xen-sources-2.6.20-r6 and xen-sources-2.6.18-r8? Is there any need to patch xen-sources kernels?

Simon

Hello,

+1
Logic would say yes : 2.6.17 onwards is vulnerable
But am I right ?
ma-ne

[d2_racing]

Hello,
+1
Logic would say yes : 2.6.17 onwards is vulnerable
But am I right ?
ma-ne

Yes, the vmsplice is there since kernel 2.6.17.

[kojiro]

OK, so anyone with half a brain knows that to get a new kernel you have to not only emerge it, but also compile it, install it, and reboot to it (or kexec).

Still, the implication of the news item:

On stable systems, do this
# emerge =gentoo-sources-2.6.23-r8

If you use ~arch keywords instead, do this
# emerge =gentoo-sources-2.6.24-r2

is that emerge =gentoo-sources-VERSION is all you have to do.

Can I talk someone into adding a link to http://gentoo.org/doc/en/kernel-upgrade.xml to the news item?

[`VL]

Gentoo isn't releasing GLSAs for kernels because of the huge amount of work to track them for all 18 of our available kernel sources and versions within each of those.

Are you serious??! Shocked to know this. Too much work?! All other software is OK, and kernel is not?
Maybe just declare on of kernels 'official' and provide GLSAs for it? I think latest avaliable gentoo-sources/genkernel are candidates.

[doppelgaenger]

I am running:

uname -a
Linux zoom 2.6.23-hardened-r4 on i686 and the local exploit works:

$ ./a.out
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] addr: 0xc041b17e
[+] root
gentoo ~ # whoami
root

When can we expect the hardened kernel update ?

[kallamej]

I am running:

uname -a
Linux zoom 2.6.23-hardened-r4 on i686 and the local exploit works:

$ ./a.out
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] addr: 0xc041b17e
[+] root
gentoo ~ # whoami
root

When can we expect the hardened kernel update ?

It's fixed in the latest testing version (-r7).

[tanderson]

OK, so anyone with half a brain knows that to get a new kernel you have to not only emerge it, but also compile it, install it, and reboot to it (or kexec).

Still, the implication of the news item:

On stable systems, do this
# emerge =gentoo-sources-2.6.23-r8

If you use ~arch keywords instead, do this
# emerge =gentoo-sources-2.6.24-r2

is that emerge =gentoo-sources-VERSION is all you have to do.

Can I talk someone into adding a link to http://gentoo.org/doc/en/kernel-upgrade.xml to the news item?

I've heard about kexec before but never really understood it. Is it possible to upgrade your kernel without rebooting(as in unmounting and shutting down)?

[dberkholz]

Gentoo isn't releasing GLSAs for kernels because of the huge amount of work to track them for all 18 of our available kernel sources and versions within each of those.

Are you serious??! Shocked to know this. Too much work?! All other software is OK, and kernel is not?
Maybe just declare on of kernels 'official' and provide GLSAs for it? I think latest avaliable gentoo-sources/genkernel are candidates.

What I've been told is that kernel developers do a spectacularly poor job of actually indicating which commits fix a given vulnerability, so it's a lot of work to find the patch. Every one also requires a minimum of 18 kernels to get stabilized by every architecture, some of which are poorly maintained and hard to get the maintainer to patch. The time that takes means by whenever we would actually be ready to release a GLSA, the next complete kernel version's probably already out.

[Voltago]

I've heard about kexec before but never really understood it. Is it possible to upgrade your kernel without rebooting(as in unmounting and shutting down)?

Since linuxbios does that in a way, I guess the answer is yes. But if you loose all system state information in the process (I think you do) and have to go through the init process again, it's not much different from rebooting.

[tabanus]

What I've been told is that kernel developers do a spectacularly poor job of actually indicating which commits fix a given vulnerability, so it's a lot of work to find the patch. Every one also requires a minimum of 18 kernels to get stabilized by every architecture, some of which are poorly maintained and hard to get the maintainer to patch. The time that takes means by whenever we would actually be ready to release a GLSA, the next complete kernel version's probably already out.

I asked almost 18 months ago for a better way of informing us about kernel security updates. I read about this story on the register earlier today, and am glad to see this thread here. It doesn't reflect well on the Gentoo community (or Linux as a whole) that this isn't easier to keep track of.