Bug 432251 - (CVE-2008-0600) CVE-2008-0600 kernel vmsplice_to_pipe flaw
CVE-2008-0600 kernel vmsplice_to_pipe flaw
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Red Hat Product Security
public=20080209,reported=20080209,sou...
: Security
: 432288 432308 432319 (view as bug list)
Depends On: 432229 432252 432253 432283
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-10 08:37 EST by Mark J. Cox (Product Security)
Modified: 2013-03-19 09:51 EDT (History)
40 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-12 11:57:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
x86_64 panic on ptpach module load (3.17 KB, text/plain)
2008-02-10 23:48 EST, Jerry Uanino
no flags Details

  None (edit)
Description Mark J. Cox (Product Security) 2008-02-10 08:37:47 EST
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.
Comment 5 Mark J. Cox (Product Security) 2008-02-10 11:39:00 EST
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 )
Comment 6 Mark J. Cox (Product Security) 2008-02-10 13:11:58 EST
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.





Comment 7 Mark J. Cox (Product Security) 2008-02-10 15:42:39 EST
Confirmed the patch blocks this issue for Red Hat Enterprise Linux 5; this
specific exploit prints "[-] vmsplice: Bad address" and fails.
Comment 9 Mark J. Cox (Product Security) 2008-02-10 17:05:50 EST
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)
Comment 10 Ola Thoresen 2008-02-10 18:16:13 EST
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.
Comment 11 Seva 2008-02-10 18:38:28 EST
Ola,

I tried that module on a test system and got:
  <name> kernel: general protection fault: 0000 [1] SMP 
Comment 12 Ryan 2008-02-10 22:29:52 EST
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)
Comment 13 agt 2008-02-10 23:12:35 EST
@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!
Comment 14 Jerry Uanino 2008-02-10 23:48:04 EST
Created attachment 294535 [details]
x86_64 panic on ptpach module load
Comment 15 Jerry Uanino 2008-02-10 23:48:52 EST
to clarify, the module from comment#10 panic's on x86_64 for me.
Comment 16 Ryan 2008-02-11 00:51:56 EST
(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.
Comment 18 Tomas Hoger 2008-02-11 02:51:58 EST
*** Bug 432308 has been marked as a duplicate of this bug. ***
Comment 19 Tomas Hoger 2008-02-11 02:58:54 EST
*** Bug 432288 has been marked as a duplicate of this bug. ***
Comment 20 Arturas Moskvinas 2008-02-11 06:08:35 EST
On kernel-2.6.18-53.1.6.el5xen (x86_64) this exploit makes kernel panic.
Comment 21 Matthew Miller 2008-02-11 06:57:25 EST
Not to detract from the real work, but can someone describe the
access-restricted bugs marked as blocking this? (Bug #432252, Bug #432253). Thanks.
Comment 22 Matthew Booth 2008-02-11 07:01:40 EST
These are simply tracking bugs for specific affected products.
Comment 23 Mark J. Cox (Product Security) 2008-02-11 08:35:18 EST
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.  
Comment 24 Russell McOrmond 2008-02-11 09:16:07 EST
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

Comment 25 Michael A. Peters 2008-02-11 09:41:33 EST
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.
Comment 26 Don Hoover 2008-02-11 11:44:06 EST
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.

Comment 27 Erek Dyskant 2008-02-11 12:06:18 EST
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/
Comment 28 Erek Dyskant 2008-02-11 12:07:40 EST
That's against 2.6.53.1.6, not 2.6.53 as I said previously.
Comment 29 Jakub Suchy 2008-02-11 13:14:37 EST
Hey boys, Debian has already fixed this, where is Red Hat? Thank you very much.
Comment 30 Matthew Miller 2008-02-11 13:18:09 EST
> Hey boys, Debian has already fixed this, where is Red Hat? Thank you very much.

Doing quality control on the produced updates, presumably.
Comment 31 csb sysadmin 2008-02-11 13:29:56 EST
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.

Comment 32 Akemi Yagi 2008-02-11 13:54:39 EST
(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.
Comment 34 Mark J. Cox (Product Security) 2008-02-11 13:56:59 EST
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)


Comment 36 Don Hoover 2008-02-11 17:01:43 EST
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.

Comment 37 J Mose 2008-02-11 19:03:12 EST
(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
Comment 38 Frank Ch. Eigler 2008-02-11 20:40:54 EST
(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.
Comment 39 Mark J. Cox (Product Security) 2008-02-12 09:44:31 EST
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. 
Comment 41 Mark J. Cox (Product Security) 2008-02-12 11:57:07 EST
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.
Comment 43 Linda Wang 2008-03-06 13:55:22 EST
*** Bug 432319 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.