Neither exploit appears to work on either of the active kernels we are using. I don't believe that the versions listed as vulnerable are accurate. The patched code affects a function that was implemented in the 2.6.23 tree and according to the discussion thread on the kernel mailing list 2.6.22 and older kernels are not affected.

i read that it was 2.6.17 to current. Since slicehost uses 2.6.16, I believe it is safe (not certain though).

Just ran it on my slice, CentOS 5.1, 2.6.16.29-xen. Doesn't work, vmsplice returns ENOSYS, as slamb said. Interestingly enough it didn't compile, seems there's a bug in CentOS' kernel headers package because asm-x86_64/page.h was empty, had to copy in definitions from asm-i386/page.h manually

Jon,

2.6.18 is vulnerable to CVE-2008-0600 it appears and not CVE-2008-0009/10. The official xen 2.6.18 branch had the patch incorporated yesterday and our 2.6.18 kernels are updated.

http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/08e85e79c65d

You will need to restart to reload your kernel.

This is what you want to see

# cat /proc/version
Linux version 2.6.18-xen (root@sh-kern) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 SMP Tue Feb 12 06:40:50 UTC 2008


This is also ok-

# cat /proc/version
Linux version 2.6.16.29-xen (root@jason) (gcc version 3.4.6 (Ubuntu 3.4.6-1ubuntu2)) #1 SMP Sun Sep 30 04:00:13 UTC 2007

Thanks Jason. First time i had to reboot my slice since i set it up. Funny had forgotten to add apache and mysql to my default run levels since i installed them all. Thanks again.

Is this OK?

$ cat /proc/version
Linux version 2.6.18-xen (root@jason2) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 SMP Fri Nov 2 06:14:54 UTC 2007

I've rebooted twice, both hard and soft, but I still get this:
cat /proc/version
Linux version 2.6.18-xen (root@sh-kern) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 SMP Tue Feb 12 06:40:50 UTC 2008

I also tried to update & upgrade, but it's still the same.

So, I have this:

Linux www1 2.6.16.29-xen #1 SMP Sun Sep 30 04:00:13 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux

No change after reboot. Am I OK?

Just noting that these are "local" exploits which rely on someone in userland having access to the compilers. My users don't get to see such things! Besides, all the example code stopped cold on exec with segmentation faults, well before privilege escalation was attained. But still, one never knows. My Ubuntu Slice (2.6.18) has been given a swift reboot in the butt and all is well once again in Sliceland! Thanks for your diligence, Jason!

Posted By: Gadget

Just noting that these are "local" exploits which rely on someone in userland having access to the compilers. My users don't get to see such things!

This is not the case, you don't need to compile an exploit on the host it is going to run on, you could copy a compiled binary from elsewhere. Having no compilers accessible is not protection.

(side-note about the forums: the "quote" button on the threads doesn't work if the message you you are quoting is not on the last page of the discussion)

@Jon

Sigh... You're absolutely right of course. I'm lucky in the sense that I don't need to give my users any form of access to the shell, or to any means of non-vetted upload (uploads via CMS are restricted and require administrator approval - binary ELFs and shell scripts are automatically detected and red-tagged), but, really, you're very right. I should never say never. But, in my case, if a user manages to get an ELF into the system, I've got much bigger problems. Still, if anyone touches ROOT shell (even via this exploit), I see it in seconds on my cellphone, and BAM, there goes the Slice. Still, you're right. You can bet that I sleep just a little bit better knowing that my Slices are patched now. The Slicehost guys do rock. I mean, how many VPS providers out there are still running unpatched versions of Apache 1.3 and PHP4, with plaintext access to control panels and such, never mind the kernel? Did I say that you're still absolutely right, Jon? :-)

I'm afraid there are more ways to execute arbitrary code than one can count. I also have declared right from the start that my silly .bashrc trick is exactly that: one line of code to merely help you a little, not take over your duties as a competent sysadmin. I have also said that it is a one-trick pony, and as you are aware, it takes many tricks to come even close to a basic level of security. The particular C code presented did in fact invoke the shell in such a way that .bashrc was called, at least on my quarantine machine. As for security on my personal Slice, which is really just a site for my hobby business, it's adequate for the job. My data is secure (read - downloaded every evening to my own machines), and everything else is merely fun. When the fun stops, the Slice gets repaved without any hesitation on my part. Here in the forum, I really just have a light-hearted intent to provoke discussion and thought, which is the first step to awareness of the issues. I would be very pleased if you shared some of your ideas with us too.

8-)

I have hit many books and have been hit with more than a few too. No matter, I absorb something everytime, so please, feel free to hit me with one!

Deleting them shouldn't be a problem. If you do have an issue open a support ticket and we can help you replace them.

I am sure it will boot just fine. I run Debian an I am also using the 2.6.18-xen kernel. This is as far as I know, the default kerner the system boot with at every boot. And if you encounter a problem, just open a support ticket.

Birger :)