> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Ewan MacMahon
> Sent: 14 August 2009 20:54
> To: [log in to unmask]
> Subject: Re: Regarding CVE-2009-2692 local root vulnerability, exploits in
> the wild
>
> > -----Original Message-----
> > From: Testbed Support for GridPP member institutes [mailto:TB-
> > > -----Original Message-----
> > > From: Testbed Support for GridPP member institutes [mailto:TB-
> > > [log in to unmask]] On Behalf Of Ewan MacMahon
> > > > -----Original Message-----
> > > > From: Testbed Support for GridPP member institutes [mailto:TB-
> > > > [log in to unmask]] On Behalf Of Ma, Mingchao (STFC,RAL,ESC)
> > > >
> > > > - If the kernel support mmap_min_addr, if it does, then
> > > > set it greater than zero;
> > > >
> > > It appears to default to 65536 on a plain SL5 x86_64 install, so for
> > > most of us the systems that support mmap_min_addr are probably
> already
> > > actually using it.
> >
> > No really. Here is the bug report "selinux policy allows addr 0
> > mappings by default"
> https://bugzilla.redhat.com/show_bug.cgi?id=511143
> > no patch released. Last updated is 2009-08-12
> >
> > Basically it does not matter if mmap_min_addr is set or not on RH5,
> > selinux will bypass it anyway.
> >
> If it's turned on. My point is that no-one should need to set
> mmap_min_addr
> explicitly since it's set by default. It doesn't actually work if
> SElinux is
> turned on, but to get the benefit you only need to disable SElinux, not
> disable SElinux /and/ set mmap_min_addr. Anyone that's already disabled
> SElinux (lustre using people, for example) is protected already.
>
>
> > > > - Disable the SELinux if you can until update is available;
> > >
> > > Bear in mind that this advice only applies to SL5 systems - the
> > > presence or otherwise of SElinux makes no difference on SL4.
> >
> > It is because SL4 does not support mmap_min_addr.
> >
> Quite so, but SL4 users needn't (and probably shouldn't) disable SElinux
>
> since it would leave them no better off.
Yes, you are right.
More information: According to CVE-2007-6434, there is an error in kernel
in mm/mmap.c function, which leads to Linux Kernel "mmap_min_addr" local
security bypass vulnerability. Kernels before 2.6.23 were vulnerable, it was
fixed in 2.6.24
Thus, Linux kernels before 2.6.23 are vulnerable to CVE-2009-2692 local root
vulnerability (which can take advantage of CVE-2007-6434). So it does not
matter if you turn on SELinux or not.
Kernels from 2.6.24 fix the CVE-2007-6434, but if SELinux is enabled, it
will bypass the "mmap_min_addr" check, at least RH5 is the case:
https://bugzilla.redhat.com/show_bug.cgi?id=511143. Therefore, for RH5, turn
off SELinux will help mitigate the problem (but the vulnerable code is still
there).
It is not over yet. There is another way to bypass Linux kernel security
check by using pulseaudio (a setuid to 0 binary). Pulseaudio can load user
specified module (attacker's payload) into memory. Detail can be found here:
http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html. Therefore,
for Kernel > 2.6.24 with SELinux disabled might still be vulnerable if
pulseaudio exists, at least for most desktop Linux it is the case. I saw it
in Fedora and Ubuntu desktop.
And that is what the exploit code I saw does, try to exploit CVE-2007-6434
vulnerability first, if failed then try SELinux bypass, if failed again then
try to use pulseaudio.
Cheers,
Mingchao
> Ewan
|