Re: [Users] New kernel vuln...
On Tue, Sep 01, 2009 at 11:56:55PM +0200, Josip Rodin wrote: AFAICT the linux-2.6.27-openvz has this obvious issue with mmap_min_addr due to security/Kconfig containing: config SECURITY bool Enable different security models depends on SYSFS !VE config SECURITY_DEFAULT_MMAP_MIN_ADDR int Low address space to protect from user allocation depends on SECURITY default 0 Should we be worried? In general, can someone update the linux-2.6.27-openvz git tree? Nothing new has shown up on git.openvz.org for two months now... -- 2. That which causes joy or happiness. ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] New kernel vuln...
Hi Scott, How about the latest RHEL4-based OpenVZ kernel? Is it vulnerable? No, it is not vulnerable simply because all vulnerable protocols are absent in the kernel (switched off in our configs). Are there any other advantages to the current RHEL5 kernel vs. the current RHEL4 kernel? Well, quite a difficult question. On the other hand - 2.6.18-x kernels are just newer, contain some improvements, in particular in performance. Not giant but still. Some new useful features like kexec/kdump - for debugging. As you've already noted - just updates for 2.6.18-x are released more often. On the other hand - if you have a stable node and do not suffer from any problem - i'd just leave it as is. -- Konstantin On 08/18/2009 07:33 PM, Scott Dowdle wrote: Konstantin (or Kir), - Konstantin Khorenko khore...@openvz.org wrote: just wanted to share the info: i checked this issue and found that 2.6.18-128.2.1.el5.028stab064.4 kernel (latest OVZ) is immune to the exploits on the issue described at http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html Exploits do not work both inside a Container and on a Hardware Node. That IS good to know. Thanks for the information. All of my OpenVZ boxes are running the latest RHEL5 kernel so those are good. How about the latest RHEL4-based OpenVZ kernel? Is it vulnerable? And if so, should we expect an update for that real soon now? I still have one CentOS4-based box running the latest RHEL4-based kernel (ovzkernel-smp-2.6.9-023stab048.6). I've heard that one can run a RHEL5 kernel on a RHEL4 host node but I haven't tried it. The machine in question I'm a little more weary of trying new things with because it is a remote machine I don't have physical access to and I want to avoid excessive downtime... but if there are a lot of RHEL4/CentOS4 host node users running the RHEL5 kernel, I'll consider switching... although on the OpenVZ kernel download page (http://wiki.openvz.org/Download/kernel) says the RHEL4 kernek is Super stable and the RHEL5 kernel is Stable. :) If the RHEL4-based kernel is vulnerable (which I'm not sure about yet) and the RHEL5 kernel isn't then that would be one advantage. Are there any other advantages to the current RHEL5 kernel vs. the current RHEL4 kernel? Thanks, ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] New kernel vuln...
On Tue, Aug 18, 2009 at 04:31:12PM +0400, Konstantin Khorenko wrote: Hi all, just wanted to share the info: i checked this issue and found that 2.6.18-128.2.1.el5.028stab064.4 kernel (latest OVZ) is immune to the exploits on the issue described at http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html Exploits do not work both inside a Container and on a Hardware Node. On 08/17/2009 10:26 PM, Michael Stauber wrote: ... The exploit allows an unprivileged user to gain root access. However: The exploit (as is) *only* works on the master node. NOT inside a VE. Somehow the virtualization already takes care of it and prevents it when someone runs it inside a VE. Michael, could you please confirm that you were able to gain root on a kernel before 64.4? The kernel is immune due to the fact that 64.4 kernel has the bypassing mmap_min_addr issue fixed: http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html - description of the problem Exploits for the current issue, in their turn, need this hole to gain root access. AFAICT the linux-2.6.27-openvz has this obvious issue with mmap_min_addr due to security/Kconfig containing: config SECURITY bool Enable different security models depends on SYSFS !VE config SECURITY_DEFAULT_MMAP_MIN_ADDR int Low address space to protect from user allocation depends on SECURITY default 0 Should we be worried? -- 2. That which causes joy or happiness. ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] New kernel vuln...
Hi all, just wanted to share the info: i checked this issue and found that 2.6.18-128.2.1.el5.028stab064.4 kernel (latest OVZ) is immune to the exploits on the issue described at http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html Exploits do not work both inside a Container and on a Hardware Node. On 08/17/2009 10:26 PM, Michael Stauber wrote: ... The exploit allows an unprivileged user to gain root access. However: The exploit (as is) *only* works on the master node. NOT inside a VE. Somehow the virtualization already takes care of it and prevents it when someone runs it inside a VE. Michael, could you please confirm that you were able to gain root on a kernel before 64.4? The kernel is immune due to the fact that 64.4 kernel has the bypassing mmap_min_addr issue fixed: http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html - description of the problem Exploits for the current issue, in their turn, need this hole to gain root access. Hope this helps. -- Best regards, Konstantin Khorenko, PVC/OpenVZ developer, Parallels On 08/17/2009 10:26 PM, Michael Stauber wrote: Hi Michael, OpenVZ Kernel jockies... Anyone like to comment on if they think this could be exploited from a guest VM to execute code on the host node? CVE-2009-2692 I tested it on Friday with the exploit from Brad Spengler, which is mentioned on this page: http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html The exploit allows an unprivileged user to gain root access. However: The exploit (as is) *only* works on the master node. NOT inside a VE. Somehow the virtualization already takes care of it and prevents it when someone runs it inside a VE. Those were my findings when I tested it on CentOS4 and CentOS5 master nodes with CentOS4 and CentOS5 VEs. Didn't test any other distributions, as they're of next to no importance to my clients. So as long as no untrusted user has local access to the master node (or somehow manages to break out of a VE) you should be fine. ... ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] New kernel vuln...
Hi Konstantin, Michael, could you please confirm that you were able to gain root on a kernel before 64.4? Confirmed. I didn't test 028stab064.4 (which was released just a few days prior to the anouncement of the exploit), but tested older kernels. With the following kernels I could get root access on the master node with the exploit, but not inside a VE: CentOS5: 2.6.18-128.1.1.el5.028stab062.3 2.6.18-92.1.18.el5.028stab060.2 2.6.18-53.1.19.el5.028stab053.14 CentOS4: 2.6.9-023stab043.2 (Very outdated, I know. Last CentOS4 box I have.) I know, it's an odd mix, but that's what I had running. Production boxes on my end usually have new kernels, internal devel boxes are often less frequently patched. The kernel is immune due to the fact that 64.4 kernel has the bypassing mmap_min_addr issue fixed: http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html - description of the problem Exploits for the current issue, in their turn, need this hole to gain root access. That's nice to know. Good job. But you're doing this somewhere else than in net/socket.c I guess? Because net/socket.c took Linus Torvalds patch just fine w/o any rejects when I rebuilt 028stab064.4 from your SRPM and patched the hole with this: -- --- ./net/socket.c 2006-09-19 23:42:06.0 -0400 +++ ./net/socket.c 2009-08-14 19:24:21.0 -0400 @@ -698,7 +698,7 @@ if (more) flags |= MSG_MORE; - return sock-ops-sendpage(sock, page, offset, size, flags); + return kernel_sendpage(sock, page, offset, size, flags); } static struct sock_iocb *alloc_sock_iocb(struct kiocb *iocb, -- -- With best regards Michael Stauber -- http://www.aventurin.net http://www.blueonyx.it ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] New kernel vuln...
Konstantin (or Kir), - Konstantin Khorenko khore...@openvz.org wrote: just wanted to share the info: i checked this issue and found that 2.6.18-128.2.1.el5.028stab064.4 kernel (latest OVZ) is immune to the exploits on the issue described at http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html Exploits do not work both inside a Container and on a Hardware Node. That IS good to know. Thanks for the information. All of my OpenVZ boxes are running the latest RHEL5 kernel so those are good. How about the latest RHEL4-based OpenVZ kernel? Is it vulnerable? And if so, should we expect an update for that real soon now? I still have one CentOS4-based box running the latest RHEL4-based kernel (ovzkernel-smp-2.6.9-023stab048.6). I've heard that one can run a RHEL5 kernel on a RHEL4 host node but I haven't tried it. The machine in question I'm a little more weary of trying new things with because it is a remote machine I don't have physical access to and I want to avoid excessive downtime... but if there are a lot of RHEL4/CentOS4 host node users running the RHEL5 kernel, I'll consider switching... although on the OpenVZ kernel download page (http://wiki.openvz.org/Download/kernel) says the RHEL4 kernek is Super stable and the RHEL5 kernel is Stable. :) If the RHEL4-based kernel is vulnerable (which I'm not sure about yet) and the RHEL5 kernel isn't then that would be one advantage. Are there any other advantages to the current RHEL5 kernel vs. the current RHEL4 kernel? Thanks, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
[Users] New kernel vuln...
OpenVZ Kernel jockies... Anyone like to comment on if they think this could be exploited from a guest VM to execute code on the host node? This seems pretty serious and exploits are in the wild. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2692 http://www.securityfocus.com/archive/1/archive/1/505751/100/0/threaded http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98 Patches are starting to work their way into the distros: http://lists.debian.org/debian-security-announce/2009/msg00179.html http://lists.debian.org/debian-security-announce/2009/msg00181.html I assume we'll need patched kernels quickly. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] New kernel vuln...
Hi Michael, OpenVZ Kernel jockies... Anyone like to comment on if they think this could be exploited from a guest VM to execute code on the host node? CVE-2009-2692 I tested it on Friday with the exploit from Brad Spengler, which is mentioned on this page: http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html The exploit allows an unprivileged user to gain root access. However: The exploit (as is) *only* works on the master node. NOT inside a VE. Somehow the virtualization already takes care of it and prevents it when someone runs it inside a VE. Those were my findings when I tested it on CentOS4 and CentOS5 master nodes with CentOS4 and CentOS5 VEs. Didn't test any other distributions, as they're of next to no importance to my clients. So as long as no untrusted user has local access to the master node (or somehow manages to break out of a VE) you should be fine. I was using the latest stable OpenVZ kernels at the time of the testing (and 2-3 older ones on internal devel boxes that hadn't been updated). My kernels are just rebuilds from the OpenVZ SRPMs with different naming (not ovzkernel, but back to kernel). The rest is stock. I already rolled up updated OpenVZ kernels for CentOS5 with the patch that Linus Torvalds posted on Friday: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98 A patched one for straight CentOS5 - *without* the OpenVZ stuff! - can be found here: http://mirror.blueonyx.it/pub/BlueOnyx/5106R/CentOS5/blueonyx/testing/RPMS/ FWIW: The RedHat 2.6.18-128.4.1.el5 SRPM has about 8-10 patches which the OpenVZ 2.6.18-128.2.1 kernel is missing.I started looking up the CVE numbers to see what the missing patches were for (if the CVE numbers were given in the changelog), but it didn't appear to be anything overly worrysome. This seems pretty serious and exploits are in the wild. Yeah, if you're running an unvirtualized Linux you should be worried. If you're running CentOS, then especially so. It just took them 9 days to release a GLIBC update and the other important kernel and bind updates before that were also so late that it was nothing to write home about. I wonder how long it'll take them this time to rebuild the RedHat kernel SRPM and release it sigh. It's no longer funny what they do. -- With best regards Michael Stauber -- http://www.aventurin.net http://www.blueonyx.it ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
