All about the system administration and application development behind a local linux-based company
I’ve built the following RPMs for RHEL 5 that fix the vmsplice() exploit in RHEL machines. They are built off of the 2.6.18-53.1.6.el kernel, with the upstream patch from kernel.org.
I’ve tested them on i686 and x86_64 machines, however be aware that they have not undergone extensive QA, so I’m not responsible if they blow up your machine. That said, I’m pretty confident that no one will have any problems with them, as they are literally a one-line difference.
Update: Reminder to install these with rpm -ivh and not rpm -Uvh. Otherwise you’ll remove your old kernels, which you may need to fall back to,.
i686:
i688-PAE:
x86_64:
Source:
Xen, and several other RPMs are available at: erek.blumenthals.com/vmsplicekernels. Note that the PAE and Xen kernels are entirely untested.
As this kernel is an odd-numbered release, yum should pick up the official upstream patch as soon as it’s available, but in case they do their numbering differently or pick the same release number that I did, it’d be a good idea to double check that yum picks up the latest.
Let me know any experiences with this, especially any confirmations that it’s safe with PAE or Xen.
February 11th, 2008 at 1:16 pm
Thanks for the fixed rpms erek, they are much appreciated. I will mirror these from my server as well
http://nix101.com
February 11th, 2008 at 3:17 pm
a big thanks for the rpms. i have mirrored them in my forums also
February 11th, 2008 at 10:43 pm
Thanks erek!
February 12th, 2008 at 3:01 am
After installing your kernel, it returns wtf message. Not sure what does it mean?
# ./t
———————————–
Linux vmsplice Local Root Exploit
By qaaz
———————————–
[+] mmap: 0×0 .. 0×1000
[+] page: 0×0
[+] page: 0×20
[+] mmap: 0×4000 .. 0×5000
[+] page: 0×4000
[+] page: 0×4020
[+] mmap: 0×1000 .. 0×2000
[+] page: 0×1000
[+] mmap: 0xf7fc1000 .. 0xf7ff3000
[-] wtf
# ./t2
———————————–
Linux vmsplice Local Root Exploit
By qaaz
———————————–
[+] addr: 0xffffffff
[-] wtf
February 12th, 2008 at 6:56 am
Odd/Even kernel version numbers no longer denote experimental/stable kernels.
All linus kernel releases are stable - he changed the process so all the instability occurs in the release candidates; there’s a 2-week window starting at the release of any kernel, in which the improvements for the next release are applied, then linus sends out a -rc1 kernel and the process of bug fixing starts until the kernel settles down and then linus releases it and the cycle starts again.
February 12th, 2008 at 7:46 am
Helvetica,
It wasn’t the kernel version I changed, it was the RPM release number (from 2.6.18-53.1.6.el to 2.6.18-53.1.7.el). I thought that redhat tends to ship even numbered release numbers, but looking back through the update archives they do sometimes ship odd-numbered ones. I doubt that they’ll number it the same that I did, but if they do, I’ll post instructions for how to add their RPM manually when it comes out.
–Erek
February 12th, 2008 at 9:19 am
wtf
I suggest care. Yesterday, during our testing, we saw this on two hosts, both kernel-2.6.18-8.el5 .
One ran only the exploit, the other was used in an unsuccessful attempt to test the live patch and wrap it as an rpm. The exploit-only host, several hours after the exploit test, suffered a kernel panic, during a quarter-hour that it was otherwise idle, and a safety reboot of the live patch test machine failed due to a /etc/passwd file overwritten with random binary data.
After cursory examination of the exploit code, I believe it indicates that the root-owned virtual memory randomly selected and corrupted by the exploit (or live patch usage of the exploit) was critical enough that the kernel panicked quickly.
Response: The live kernel module has been known to cause kernel panics. See bugzilla.redhat.com/show_bug.cgi?id=432251#c14 for details. –Erek
February 12th, 2008 at 9:23 am
wtf
Lest I inadvertently scare anyone away from testing for vulnerability and taking corrective action, I should add:
Both machines were fully recovered, though both hosts required testing time, and the patch test host required restoring /etc/passwd from a backup.
Thank you erik.
February 12th, 2008 at 9:55 am
Hung,
just try to run that exploit without root privileges :^)
February 13th, 2008 at 8:59 am
[…] http://erek.blumenthals.com/blog/2008/02/11/rhel-5-centos-5-kernel-rpms-patched-against-vmsplice-loc… […]
Translation: “Patches for the kernel vulnerability.” A blog with instructions in spanish to patch various distributions.