Grsec kernels and sock_sendpage root exploit

[closet geek]

Spender,

I see you are well aware of this exploit and have written code to exploit it. However are people who run grsec immune from this as is? We don't run PAX just grsec, what parts of grsec would need to be running to stop this?

http://blog.cr0.org/2009/08/linux-null- ... ue-to.html

Thanks.

[specs]

If I look at the diff between the 200908090749 and 200908132040 I see 2 differences. One would be an pax-fix (interdiff test21-test22).

The other is adds a little code to sendpage:
> - ap.gs = 0;
> + ap.gs = __KERNEL_STACK_CANARY;
And some cleaning up:
> - return sock->ops->sendpage(sock, page, offset, size, flags);
> + return kernel_sendpage(sock, page, offset, size, flags);

Since the exploit is based on executing code at NULL I would think enabling PAX (and UDEREF) would be enough to prevent most damage.

I expect you are also familiar with CVE-2009-1894 since you posted the link to CVE-2009-2692 at the same blog.

PS for a production machine I think the 2.6.29.6-version of the patch is currently still the better choice, however your mileage may vary.
PPS you might check the RH bugreport. If you compile your own kernels you could find most problems are not present in your configuration if all the affected modules are missing.

[crusader]

Hello,

I tested the exploit on x86 & x86_64 2.6.27.6-grsec kernels

with the following Grsec config:

CONFIG_GRKERNSEC=y
CONFIG_GRKERNSEC_CUSTOM=y
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_IO=y
CONFIG_GRKERNSEC_BRUTE=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USER=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_SOCKET=y
CONFIG_GRKERNSEC_SOCKET_SERVER=y
CONFIG_GRKERNSEC_SOCKET_SERVER_GID=2000
CONFIG_GRKERNSEC_FLOODTIME=5
CONFIG_GRKERNSEC_FLOODBURST=10

---------------------------------------------------------------------------
With vm.mmap_min_addr=0, the exploit fails at that stage because can't obtain access to /proc/kallsyms
due the grsecurity proc restrictions:

/tmp/exploit/wunderbar_emporium$ ./wunderbar_emporium.sh
[+] MAPPED ZERO PAGE!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
Unable to obtain symbol listing!
unable to find a vulnerable domain, sorry

---------------------------------------------------------------------------
With vm.mmap_min_addr=1

the exploit fails again, because I don't have pulseaudio installed

/tmp/exploit/wunderbar_emporium$ ./wunderbar_emporium.sh
[+] Personality set to: PER_SVR4
Pulseaudio does not exist!

Could you tell me if my setup is vulnerable to this vulnerabillity ?

Thank you

[PaX Team]

I see you are well aware of this exploit and have written code to exploit it. However are people who run grsec immune from this as is? We don't run PAX just grsec, what parts of grsec would need to be running to stop this?

short answer: for this kind of bugs only i386/KERNEXEC provides protection (i.e., amd64/KERNEXEC does not).

now the long answer as i see many people are confused about what kind of bugs and exploits are affected by what methods.

first, let's talk about the bug class in question briefly. the most generic description could be something like "kernel code dereferencing an unwanted pointer". this can further be split into subclasses, depending on the type of dereference (data read, data write, code execution) and where the pointer points to (memory under direct userland control, kernel memory under indirect userland control, kernel memory under kernel control). that'd give us 9 subclasses, e.g., the sock_sendpage bug is 'code execution' and 'memory under direct userland control'. obviously each subclass gives a different kind of power into the exploit writer's hands, from userland controlled code execution being the best through leaking kernel memory to userland to causing a harmless oops or nothing at all. then one can also combine multiple such bugs to increase the power of the exploit (e.g., the vmsplice exploit first made the kernel read data under userland control then turned that into code execution in userland controlled memory).

now let's see what we can do about these subclasses (or rather, exploits, since we don't prevent the bugs from getting triggered, only their exploitation, if possible, that is). there're two PaX features that affect these exploits: KERNEXEC (i386/amd64) and UDEREF (i386). let's see what each one of them can do.

i386/KERNEXEC: this feature is primarily about implementing non-executable pages for i386 CPUs, even for those without a hw NX bit (as such CPUs didn't even exist back in 2003). due to the way it's implemented, it actually achieves more: it not only properly separates executable pages from non-executable ones in the kernel's virtual address region, it also makes the userland virtual address region non-executable as well (that is, non-executable by the kernel, userland can of course still execute there). so this feature affects all exploits that want to execute code in that such execution is restricted to the kernel's executable region. if the exploit has no control over the code pointer being dereferenced and/or it points outside of the kernel's executable region (e.g., it's a NULL function pointer as in the sock_sendpage case) then such exploits have no chance to succeed (they can however still cause problems since when the code execution attempt is caught, the kernel may be in a state where terminating the current thread may result in a deadlock or even memory corruption leading one into other exploitable situations). data dereference based exploits or code execution attempts in the kernel's executable region (think ret2libc for the kernel) are not affected by this feature.

amd64/KERNEXEC: this is similar to the i386 version in that it also implements proper executable/non-executable page separation for the kernel, but there's a big difference in that it does so only for the kernel's virtual address region, it leaves executable userland regions, well, executable for the kernel as well. in this particular case, if userland can map memory at NULL then it will be executable by the kernel and hence this bug is exploitable under amd64 even with KERNEXEC enabled. fixing this is a hard problem as AMD had butchered the segmentation logic and the alternative (address space switch on each userland/kernel transition) has a high performance impact (as a sidenote, it'd also enable UDEREF for amd64). i may still implement this one of these days but don't expect wonders, especially under virtualization.

i386/UDEREF: this feature is about separating userland/kernel virtual memory for data accesses. therefore it doesn't prevent/affect code execution attempts at all, on the other hand it catches all data accesses to userland when the kernel isn't supposed to access userland (e.g., NULL data pointer dereferences are caught this way).

finally, some notes on other archs: there seems to be some confusion about certain archs such as sparc that have a separate kernel virtual address space and therefore seem immune to this "unwanted pointer dereference" problem. this is actually not true in general, of the 9 subclasses above some are exploitable even there: both data and code pointer dereferences will succeed when they point at valid kernel addresses and much of that memory can be indirectly controlled by userland (think page cache for example) so it'd be important to tighten up page access rights for the kernel's address space as well (something i already began to do on amd64 for example, you can see it on the kmaps results).

[Grach]

data dereference based exploits or code execution attempts in the kernel's executable region (think ret2libc for the kernel) are not affected by this feature.

Speaking of ret2libc, one can build a relocatable kernel and randomize its alignment in memory at boot time. Can such randomization help the kernel to stand better against ret2libc-like attacks, what do you think?

[PaX Team]

Speaking of ret2libc, one can build a relocatable kernel and randomize its alignment in memory at boot time. Can such randomization help the kernel to stand better against ret2libc-like attacks, what do you think?

it's very coarse randomization (you get few bits) and trivially broken by info leaking...

[mikeeusa2]

Dear PAXTeam:

Currently I'm running a 6 year old 32-bit AMD SMP machine as my server with grsecurity kernel and everything locked down, LUKS encrypted hdd aswell.

In the future, if a total economic collapse of the United States of America fails to occur, I _MAY_ wish to build a new server, perhapse a quad-cpu + quad(or 6x if they have those)-core computer box with grsecurity kernel, and LUKS encrypted ssd (for root) and hdd (for users).

It sounds like amd style 64 bit cpus are less secure? (Same for intel?). What cpus should I choose for the greatest amount of security?

[felosi]

Got email reply from support, resolved. Im posting it here in case anyone else comes across this thread

On 23 Aug 2009 at 4:40, Jon Felosi wrote:

> > I gathered from your forum that the 64 bit grsec kernels are still vuln
> > to the exploit you released.

no, you misunderstood. what PaX (and hence grsec) on amd64 is vulnerable to
is the *bug class*, not this particular bug which had already been fixed
both upstream and in grsecurity the day it became public (we also backported
the fix to the 2.6.29.6 patch as the kernel developers don't support that
version themselves anymore).

> > Are there any patches on the site that I can compile a kernel with and
> > be protected against all these recently released exploits from you and
> > the others out there?

the patches are in the usual places, easiest access is at http://grsecurity.net/test.php .


My oversight and misunderstanding. I wasnt clear on whether the patched kernels were vuln to the exploit releases or not.

[mikeeusa2]

felosi: the exploit exists weather a script is written for it or not. Just because you don't know about it doesn't mean you're secure.

[PaX Team]

It sounds like amd style 64 bit cpus are less secure? (Same for intel?). What cpus should I choose for the greatest amount of security?

as far as PaX is concerned, the 32 bit i386 kernel is best for security, it doesn't matter if you run it on an otherwise 64 bit capable intel/amd processor (but for having NX support they're preferable too, not that it's easy to find a CPU without it these days).