Brad Spengler (spender), grsecurity developer, posts Linux security exploits, interview notes, and the odd joke image.
Commenters cite his interview notes as a critique of Linux security practices, such as undisclosed fixes, and as a sign he's frustrated with upstream.
> 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…
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-linux-closet.html
[2] http://grsecurity.net/~spender/64bit_dos.c
> 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.
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.
> 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.
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.