Linux gets fix for code-execution flaw (Ars Technica)

and for a generic defeat (doesn't require any vuln, can be done inside heavy seccomp):
https://grsecurity.net/~spender/kaslr.png
Want to guess where the kernel is? ;)

spender@www:~$ ls -al kaslr_generic_defeat32.c
-rw-r--r-- 1 spender spender 2854 Apr 21 00:34 kaslr_generic_defeat32.c
spender@www:~$ ls -al kaslr_generic_defeat64.c
-rw-r--r-- 1 spender spender 2801 Apr 22 19:40 kaslr_generic_defeat64.c
spender@www:~$ sha256sum ./kaslr_generic_defeat32.c
8e394f7511e36ba43469cc4d9961e51e462510d09dba380519c85efbab24ae10 ./kaslr_generic_defeat32.c
spender@www:~$ sha256sum ./kaslr_generic_defeat64.c
b72836de6cf512c59a889dae92e928efecc321c45b00b6bec461e45917f703ae ./kaslr_generic_defeat64.c

Also, I never called Kees an idiot -- I like Kees. I don't like bad security or cargo cult security though, and that's what I've repeatedly pointed out (https://forums.grsecurity.net/viewtopic.php?f=7&t=3367). If we felt KASLR was at all worthwhile, we would have done it ourselves years ago, but it's simply not. With all the information we've put forth so far though and that in academic literature, there could be an argument for labeling as 'stupid' a person who still believes contrary to all available evidence regarding the usefulness of KASLR.

-Brad

Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org stock@stokkie.net

Regarding RANDSTRUCT/HIDESYM, we also have a feature to prevent attempts at bruteforcing kernel exploits. Unlike panic_on_oops, where possible we will instead terminate all the attacker's processes and ban their account until system reboot. I'm of the opinion that real (aka non-script kid) attackers won't risk an 0day if their exploit isn't extremely reliable. You wouldn't want oopses to be remotely logged that give away the location of the vulnerability, for instance.

You won't get far with trying to guess addresses for specific functions in the kernel ;) You will need specific exploit vectors or additional vulnerabilities to reliably determine these. In either case you'll run into a number of other features (other parts of HIDESYM, STACKLEAK, STRUCTLEAK, SANITIZE, etc).

That said, we've never been the type to rest on our laurels, so we continue to introduce new protections to close up existing weaknesses in the kernel. We hope to announce another one of these soon ;)

Speaking realistically, if we assume this vulnerability was known since commit time (unlikely due to the nature of this vuln) then there would possibly be a private exploit developed by some very skilled person. If we think of the number of skilled people who could pull off an exploit of this type, the number with knowledge of the vulnerability and access to that private exploit would be a much smaller subset. The risk to everyone by an attacker like that would be low: they'd be launching very targeted exploits and likely have better vulnerabilities than this one.

Now that the vulnerability is public, a different game is created. Now presumably all the people that could pull off the exploit against a grsecurity system are aware of the vulnerability and can begin creating an exploit. I updated all of our patches the same day the vulnerability went public and noted at the time in public that I expected to see an exploit for it within the month. Now the only relevant question for users is whether a reliable exploit can be developed and launched on their system before they're able to update. Generally in the past even when we've seen vulnerabilities that grsecurity wouldn't help much against, the exploits that have been published haven't worked on grsecurity kernels. It's simply much harder to develop reliable exploits and not being able to use easily generalized techniques like those I use in enlightenment means exploit development time increases as well. Upstream/distro users are at a severe disadvantage here compared to users of grsecurity. The only protection upstream has to kernel exploits is to fix the vulnerability.

We don't base our defenses only on the exploits we write ourselves. I don't know that I personally would be able to develop a reliable exploit for this vuln against a grsec kernel in any reasonable amount of time, but I'm also not too interested in spending a lot of time on it and taking away from legitimate work. We have identified plenty of areas for improvement that I would rather spend time on instead. My interest in developing exploits against the upstream kernel generally fades out after a day or so -- luckily I've been able to complete them all in that amount of time ;)

-Brad