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

Posted May 13, 2014 14:23 UTC (Tue) by error27 (subscriber, #8346)
In reply to: Linux gets fix for code-execution flaw (Ars Technica) by spender
Parent article: Linux gets fix for code-execution flaw (Ars Technica)

[ bugfuzz.com is down so I can't see the actual exploit ]

Regarding HIDESYM, if you have kaslr enabled (CONFIG_RANDOMIZE_BASE) then the "download system.map" trick doesn't work.

You keep on calling Kees an idiot whenever he merges a partial solutions but in the end he kept merging parts until he had made a real life improvement to security.

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

Posted May 13, 2014 16:07 UTC (Tue) by spender (guest, #23067) [Link] (3 responses)

Two defeats that work against even the latest 3.14.4 with KASLR:
https://www.youtube.com/watch?v=-Tw_sYmI4LQ
https://www.youtube.com/watch?v=S7BQ7qDz028

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

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

Posted May 13, 2014 16:34 UTC (Tue) by torquay (guest, #92428) [Link] (2 responses)

This is comical and sad at the same time. Care to make the exploits public? Also, why isn't the National Stasi Agency knocking on your door to enhance its 0-day arsenal ?

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

Posted May 13, 2014 17:47 UTC (Tue) by spender (guest, #23067) [Link]

I'll publish them only if/when the underlying problems are fixed (which I don't think it can/will be in the case of the generic attack). We did more than enough already by pointing out the problems with KASLR in our blog post, so if people want to ignore that advice and the attacks documented in academic literature (which I have reproduced), then I don't feel they should be able to have their cake and eat it too. Especially when people are so bug-obsessed that fixing two trivial defeats will give the impression that KASLR is useful again.

As for the last question, I imagine they have purchased more than enough exploits already from the rest of the "security industry" (aka exploit mercenaries).

-Brad

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

Posted May 14, 2014 18:51 UTC (Wed) by nix (subscriber, #2304) [Link]

How do you know it isn't?

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

Posted May 13, 2014 17:18 UTC (Tue) by stock (guest, #5849) [Link]

In the fall of 2009 electricity was disconnected to my house, in Dec 2009 I was out of a place to stay. Today i inserted a new lock into the frontdoor of my new little condo. What happened in between, i don't know. Lots of missing time online. I do know that a guy called Snowden has pissed of a lot of folks. This afternoon i read here that since Sept 2009 all new released Linux kernels have been vulnerable in a very ugly manner.

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

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

Posted May 13, 2014 18:17 UTC (Tue) by kees (subscriber, #27264) [Link] (6 responses)

With regard to HIDESYM, upstream has the sysctls "kptr_restrict" and "dmesg_restrict" that can help with some classes of disclosure (e.g. zeroing kernel pointers in things like /proc/kallsyms, /proc/$pid/stack, and blocking dmesg reading). They work best when combined with a custom build, of course.

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

Posted May 13, 2014 18:42 UTC (Tue) by spender (guest, #23067) [Link] (5 responses)

Except here those upstream protections don't matter. Even in the event of a custom kernel, because there's no KERNEXEC/UDEREF and the symbols being looked up are only used *after* they have full control in userland of the kernel's control flow, they can simply plug in my enlightenment code to reliably resolve kernel symbols using the kernel's internal symbol table. Since they have full control, they can also perform effectively the same action without the use of any kernel functions (the old/new technique of scanning the task struct for cred pointers and clearing the uids/gids in it).

By "work best" you mean "do much of anything at all" which conflicts with their presence and promotion as security features in distributions.

-Brad

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

Posted May 13, 2014 19:25 UTC (Tue) by kees (subscriber, #27264) [Link] (4 responses)

We (commonly) disagree about the utility of these features. My goal is always to push the bar higher on exploitation difficultly. I'm always sad to see these exploits that ignore various mitigations. This _specific_ exploit mentioned is blocked by kptr_restrict=1. (Chrome OS and Ubuntu set this by default, btw.) It could totally have been written to do symbol resolution differently, but it wasn't. As long as existing mitigation methods remain disabled on some distributions, there will be no real progress since the low hanging fruit remains exposed there.

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

Posted May 13, 2014 20:34 UTC (Tue) by andresfreund (subscriber, #69562) [Link]

> As long as existing mitigation methods remain disabled on some distributions, there will be no real progress since the low hanging fruit remains exposed there.

Well, it's simply not a very clear win on distributions that aren't primarily used for web browsing and light desktop activity. For me the existence of kptr_restrict frequently is a *major* PITA. Part of my job is analyzing bottlenecks on foreign servers. Not having kernel symbols available when profiling *sucks*. So either I have to get root - surely not a gain in security - or kptr_restrict and perf_even_paranoid have to be changed.
Only providing global flags kptr_restrict is too simplistic for the real world.

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

Posted May 14, 2014 12:17 UTC (Wed) by ballombe (subscriber, #9523) [Link] (2 responses)

What would be the benefit of having a more robust public exploit ?

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

Posted May 14, 2014 14:39 UTC (Wed) by kees (subscriber, #27264) [Link] (1 responses)

My belief is that defending against real (or at least "more realistic") exploits means defensive work/research will address more realistic scenarios instead of designing mitigations against toy exploits.

Frequently, upstream mitigation work is more about socializing a solution than creating the actual technical work. Without solid examples of what a mitigation is designed to defend against, it can be hard to convince maintainers of its need.

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

Posted May 14, 2014 18:31 UTC (Wed) by ballombe (subscriber, #9523) [Link]

Well, you can publish more robust exploit yourself.