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...)
I see 2.6.23.15 has been built in Koji. When is this going to get pushed into stable updates?
*** Bug 432244 has been marked as a duplicate of this bug. ***
Relevant information about patch: http://lkml.org/lkml/2008/2/10/118
Relevant discussion at gmane.linux.kernel mailing list: http://thread.gmane.org/gmane.linux.kernel/637339
Bringing in RH Security Response team.
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!
Fixing CVE name, the exploit "jessica_biel" is for CVE-2008-0600
*** Bug 432263 has been marked as a duplicate of this bug. ***
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
Fixed in: kernel-2.6.24.1-28.fc9 kernel-2.6.23.15-137.fc8 kernel-2.6.23.15-80.fc7
kernel-2.6.23.15-137.fc8 has been submitted as an update for Fedora 8
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 }'
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 probe(s), 0 function(s), 0 embed(s), 0 global(s) in 10usr/0sys/6real ms. Pass 2: analysis failed. Try again with more '-v' (verbose) options.
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.
(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) }
Can you please supply a complete systemtap script for versions older than FC7?
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 }'
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 oystein ptpatch2008: syscalls ffffffff81270780 hooked sys_vmsplice $ ./exploit_test [...] [-] vmsplice: Invalid argument $ dmesg | tail -4 ptpatch2008: init, (c) 2008 oystein ptpatch2008: syscalls ffffffff81270780 hooked sys_vmsplice ptpatch2008: possible EXPLOIT attempt by uid 500.
I've grabbed the koji build, any word on when the fix will be pushed to updates[-testing]?
(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 oystein > ptpatch2008: syscalls ffffffff81270780 > hooked sys_vmsplice > $ ./exploit_test > [...] > [-] vmsplice: Invalid argument > $ dmesg | tail -4 > ptpatch2008: init, (c) 2008 oystein > 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
FYI ptpatch2008 under fc6 yields this: ptpatch2008: init, (c) 2008 oystein ptpatch2008: no sct, bailing out
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.
On an unpatched 2.6.23, I got this: Feb 11 20:56:52 holly kernel: ptpatch2008: init, (c) 2008 oystein 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.
FYI..this ptpatch2008 kernel module compiles fine, but causes a GPF/crash on a AMD64 box when insmod is attempted.
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.
Will kernel-xen packages also be created?
(In reply to comment #26) > Will kernel-xen packages also be created? > bug #432517 was created to track kernel-xen packages.
*** Bug 441414 has been marked as a duplicate of this bug. ***