[Users] New kernel vuln...

Konstantin Khorenko khorenko at openvz.org
Tue Aug 18 08:31:12 EDT 2009


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.
> ...


More information about the Users mailing list