Security quotes of the week

Joining an Amish community, then?

The linux.com PR piece which both the Linux Foundation and Greg KH promoted with an "EXCLUSIVE:" title:
https://plus.google.com/+LinuxfoundationOrg/posts/FkSbr3P...
https://plus.google.com/+gregkroahhartman/posts/2rM46nj9RsL

has been updated! The update claims:
"Editor's Note: This article has been updated to clarify security changes in the 4.6 release."

Feel free to compare the archived version of the linux.com post to the new "clarified" version:
https://web.archive.org/web/20160515221843/https://www.li...

You will find that the only change made (other than to refer to the release of 4.6 in the past tense) is replacing the following sentence:
"If something happens and you can't override a data structure, you can't."
to
"If a bug happens where you would normally be able to overwrite a portion of memory, now with the added protections in place, you aren't allowed to do that so the bug does not cause any additional "harm.""

So the only change was to replace a nonsensical sentence with one that's factually incorrect. It acts as if stopping one minor post-mem corruption exploit vector is the same as stopping a bug class. As I already explained in the original LWN post about __ro_after_init, an attacker abusing the VDSO generally already has an arbitrary write primitive. Thus it's not at all the case, as the linux.com article claims, that the bug cannot cause any additional harm. Trivial proof of this is given by the other exploit published for the CTF which instead of targeting the VDSO, did a direct modification of the task's cred struct. It's unconscionable to me that Kees and Greg would stand behind this piece of security word salad, but I'm sure it's indicative of their future strategy to compete by trying to co-opt our "kernel self-protection" term while offering little more than cargo-culted, minimal effort, fluff. And we'll continue to fight back with facts.

You can see Greg's response to my blog post in his post above. Clearly he's not concerned about spreading misinformation while trying to market upstream's cargo cult security attempts.

What Greg's comment on the article (and his final comment where he, funded full time by the Linux Foundation, dreams of a world where we wouldn't be able to work on security full-time) really exposes, is that Kees is being used merely as a surrogate to lessen the blows to upstream egos. To admit to us personally that they were wrong all these years would be too much for their egos to bear, so instead they'll take the same exact advice (see my LSS 2010 talk) from someone else who sucks up to them while they copy+paste and remains silent as they disrespect our work as Greg did in his above comments.

Believers in the KSPP need to ask themselves a hard question: with the people doing the upstreaming work incapable of understanding the code enough to do anything more than literal copy+pastes (see the RANDSTRUCT, USERCOPY, and KSTACKOVERFLOW copy+paste "work" as evidence of this) -- who is going to maintain that code if it ever lands upstream? The submitted patch for USERCOPY today couldn't possibly have ever been tested; it's a straight copy+paste with irrelevant grsecurity hunks left in and significant portions entirely missing.

So that I don't get accused of being anti-everything, I will add that there are other people doing useful security-related work for Linux: Hannes Frederic Sowa, Andy Lutomirski, Daniel Borkmann, Dan Carpenter, and Mathias Krause. Though much of it was already done in i386 UDEREF in 2006, Andy's uaccess branch that overloads uaccess exception handling to put some limits on KERNEL_DS activity is a welcome change. Daniel Borkmann recently put out the first version of the eBPF JIT constant blinding (which I did for the older BPF years ago) and has made the effort to have it support a wide array of architectures. Understood in the proper context, this is all good stuff. In the ideal world, it would be these people doing real work we're acknowledging instead of people copy+pasting code and making the minimal effort to claim some new security feature. In this world, unfortunately, we ignore 15 years of work and pretend someone sweet-talking us into copy+pasting some code is the only thing deserving of recognition. As I mentioned before, this is a highly short-sighted strategy that isn't going to work out well in the long term.

-Brad