Brad Spengler

> you gave me an example. Ahh sorry. Well to continue along that example, evidently it breaks out of lots of things -- https://grsecurity.net/~spender/logs.txt > On PaX, the kernel supports utilizing the NX bit on x86-64 and has for quite a while now. Not using a system supporting the NX bit or at least PaX/Exec Shield is pretty stupid. Not going to try to parse this, but you appear to be very mistaken. Wikipedia PaX. > VMs are not entirely isolated from the host system Correct, hence the parenthetical in the OP. That sysret bug was a great one.

https://grsecurity.net/~spender/interview_notes.txt he seems to admit defeat in what he is doing and upstream here more or less.

From @lattera on Twitter: here's a couple lost pages found by the grsecurity folks: https://grsecurity.net/~spender/pics/lost_selinux_coloring_book_page1.… https://grsecurity.net/~spender/pics/lost_selinux_coloring_book_page2.… :)

Linux being secure is a fallacy too. Spender talks about it for a long time: https://grsecurity.net/~spender/interview_notes.txt Linux developers fix security bugs in irresponsible ways, saying nothing about the attack vector or CVE's involved. Sometimes multiple vulnerabilities are addressed in the same patch, making hard to track the fix. For more information see the exploit below: https://grsecurity.net/~spender/exploits/64bit_dos.c The list of kernel vulnerabilities involving namespaces is bigger each day, as the paper shows, but the industry still uses "container" and "security" in the same quotes.

Related to the recent interview notes by Brad Spender: https://grsecurity.net/~spender/interview_notes.txt IMO it's scary to hear Linus say that "security is just stupid bugs" and that he doesn't think about containers much (container/namespace security and functionality is a big and quickly emerging part of the kernel security landscape). Call it a lack of vision or whatever, but I think he should be doing more to architect for security and to recruit, place and reward talented people into security lead positions in the kernel community.

I think "spendy" is his irc nick. And "spender" is his grsec machine nick https://www.grsecurity.net/~spender/

> This is likely to be easy to exploit for privilege escalation, except on systems with SMAP or UDEREF Another reminder why everyone should be using https://grsecurity.net which provides these mitigations to the Linux kernel via patches. GRSecurity has had SMAP aka KERNEXEC for a long time as well as UDEREF https://grsecurity.net/~spender/uderef.txt If you keep any sensitive data on a Linux server you should seriously consider grsec. Even last week there was an ASLR bypass posted on OSS-security which of-course grsec already protected you against http://seclists.org/oss-sec/2014/q4/908 There is a lot of drama around the fact Linux core devs don't adopt these patches by default. But regardless Linux is pretty insecure by default and grsec makes privesc via various classes of exploits significantly harder.

Reminded me of this diagram: https://grsecurity.net/~spender/pics/mac_security_sesamestreet.jpg

A variant on http://grsecurity.net/~spender/msr32.c would have worked up until the capability check was added. Capabilities will help you, but if your business model is built on the assumption that the kernel performs capabilities checks everywhere it should then you really ought to be actively reviewing kernel entry points yourself.

> With SELinux root can build systems which are so secure that root himself cannot hack them. Sounds like your administrator would be well served to spend more time studying real-world vulnerabilities and less time focusing on SELinux :) See eg. http://grsecurity.net/~spender/exploits/exploit2.txt

As taken from spenders twitter, here are the relevant parts of the patch: http://grsecurity.net/~spender/jit_prot.diff

Oh, you're talking about regression testing. While you have a point, I'd like to point out a recent vulnerability [1] that would likely fail many a test for two reasons: - The bug is not concrete. It's not entirely in the kernel, and it's not entirely in userspace. - The developers have a poor understanding of the bug. The current "fix" only mitigates the problem. There are system configurations where it can still be exploited. There are other issues [2] that arise from large address space management that are waiting to be fixed because of this. But I agree that regression testing for the whole kernel tree should probably be implemented. (for the various subsystems, many developers develop their own test suites) [1] http://theinvisiblethings.blogspot.com/2010/08/skeletons-hidden-in-lin… [2] http://grsecurity.net/~spender/64bit_dos.c

> No compiler is going to go out of its way to compile an increment into the machine's usual increment instruction and an additional overflow check that does whatever, just because it can What people are actually worried about is when the compiler starts removing - not adding - seemingly unrelated code in a hard to reason about fashion. And compilers absolutely will go out of their way to do this in the name of optimization and performance. And it will do this because it got smart enough to prove that the "unrelated" code can't run without first technically invoking undefined behavior, at which point it can jump to the wild conclusion that it must never actually execute (or that it can remove the code even if it does, because it's legal for the compiler to do anything after invoking undefined behavior - including not execute that code!) Sometimes the removed code is important security checks, leading to CVEs, hotpatches, etc. - this is not theoretical, and is not remotely new at this point: https://www.grsecurity.net/~spender/exploits/cheddar_bay/exploit.c It also makes reporting compiler bugs annoying, as you first have to definitively prove to yourself and the compiler guys that you've actually got a compiler bug, rather than a compiler "feature" of aggressive optimization within the letter of the C++ standard. It's only out of pure stubbornness that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658 got reported upstream, I was assuming it was UB in our codebase…