The Truth about Linux 4.6
Posted: Sat May 14, 2016 1:06 pmAs anticipated in public comments, the Linux Foundation is already beginning a campaign to rewrite history and mislead Linux users. Their latest PR release can be found at: https://www.linux.com/news/greg-kh-update-linux-kernel-46-next-week-new-security-features, which I encourage you to read so you can see the spin and misleading (and just plain factually incorrect) information presented. If you've read any of our blog posts before or are familiar with our work, you'll know we always say "the details matter" and are very careful not to exaggerate claims about features beyond their realistic security expectations (see for instance our discussion of access control systems in the grsecurity wiki). In a few weeks I will be keynoting at the SSTIC conference in France, where a theme of my keynote involves how little critical thinking occurs in this industry and how that results in companies and users making poor security decisions. So let's take a critical eye to this latest PR spin and actually educate about the "security improvements" to Linux 4.6.
In response to the question "What is the hard truth about Linux kernel security that many people don’t want to hear?" Greg KH mentions how Linux users need to be running the latest kernels, citing as evidence a specific "infamous" TTY vulnerability. Presumably this vulnerability was not this one for which an exploit was released within a week of publication of the vulnerability and affected the latest kernels at the time as well as those for the previous five years. To date, no exploit for that vulnerability has ever been released that would work against a kernel secured with grsecurity.
In describing this vulnerability, Greg says:
As best I've been able to tell, the details of this "infamous" vulnerability have taken on new life through a fish tale. What Greg seems to be referring to is this vulnerability (CVE-2015-4170), which for most people wasn't memorable at all, and perhaps only "infamous" because of Greg's response to it, decrying the assignment of CVEs for vulnerabilities that have been implicitly fixed in newer upstream kernels. From that same thread we can see that all the claims in the quote are false. The bug couldn't have been used to get root, it caused a DoS-only deadlock (discovered by running a reproducer for the other vulnerability I mentioned above). The 2 years in the fish tale also suddenly became 3 years.
The real "hard truth" about Linux kernel security is that there's no such thing as a free lunch. Keeping up to date on the latest upstream kernel will generally net all the bug fixes that have been created thus far, but with it of course brings completely new features, new code, new bugs, and new attack surface. The majority of vulnerabilities in the Linux kernel are ones that have been released just recently, something any honest person active in kernel development can attest to. I commented as such back in 2010 on an LWN article about whether kernel vulnerabilities were old or new: https://lwn.net/Articles/410674/. I had claimed at the time that the methodology used in the post, which showed that vulnerabilities lasted on average 5 years before being discovered, had been biased in its conclusions by only relying on CVE statistics. As I noted in the comment, it was common practice at the time (though it seems to have improved slightly since) that when reporting a recent vulnerability on oss-sec, Red Hat wouldn't request a CVE as it didn't affect any of their distribution kernels, and none would subsequently be allocated. Comments in reply to that post from Dan Carpenter and others discuss the many other vulnerabilities found that weren't assigned CVEs.
We just saw an example of new changes introducing vulnerabilities recently with eBPF as noted in our previous blog post. The use-after-free vulnerability in eBPF which just recently was allowed to be accessed by unprivileged users, had a published exploit within a week of the bug's public disclosure: https://bugs.chromium.org/p/project-zero/issues/detail?id=808. Again, grsecurity was unaffected by this vulnerability. Add to this the hopefully now well-known plethora of vulnerabilities plaguing the introduction of unprivileged user namespaces.
So the real "hard truth" is that Linux is just now starting to play catch-up in the game of kernel self-protection that we've been playing for 13 years. Finally perhaps they've gotten the message that relying on updates alone doesn't provide any security, even against the least skilled attacker. You're always one 0day away from complete system compromise using the same old techniques that are known and dead in grsecurity for years. For all the talk of raising attacker cost, what's the cost to an attacker that downloads a fully-functional public exploit? Real security defenses make exploitation impossible for relevant bug classes and exploit vectors, and force attacks to more difficult unpublished techniques that are more time-consuming, harder to automate, and harder to perfect in an attacker's test environment.
Later in the article where Greg talks about how companies and users need to use the latest releases so that they get not only the most bugfixes, but also the newest security features, he says:
On its face, this quote is utter nonsense -- hopefully only terribly misconstrued from Greg's supposed words (maybe the interview was over phone and transcribed poorly -- override vs overwrite etc). Ignoring all that, what Greg appears to be referring to is the addition of __ro_after_init, a renamed implementation of what in grsecurity and PaX we've had and called __read_only for the past 8 years. The idea of the feature is to make certain global kernel variables and data-structures read-only after they've been initialized by early kernel init code, protecting them against direct modification at runtime. A quick grep through our latest patch shows we're using this marking on about 200 global variables and data structures important to the kernel's security. In the to-be-released Linux 4.6, this feature protects exactly *one* thing, as a common theme seen in upstream security, the bare minimum effort required to claim support for X and publish an entire PR piece about it. Of course, in cherry-picking a tiny subset of a tiny feature in grsecurity, they fail to mention what it doesn't cover: that it doesn't have support for marking in modules like we do, nor does it allow to mark the many things we do which need to be written after init, but infrequently enough that we are able to make them ambiently read-only.
As seen with other upstream security features, once that claim of support for X is made, little is done to improve it or fix fundamental weaknesses. KASLR, a failed security mitigation introduced in Linux 3.14, continues to be as irrelevant as ever. Just in the past week a half dozen or so stack-based information leaks were published by academics at Georgia Tech, each one a KASLR defeat. The attacks published in academic literature (mentioned in our KASLR blog post prior to the addition of KASLR to Linux) still work today as a generic bypass. While work continues (currently on its 8th revision) on "improving" KASLR, the improvements are all completely orthogonal to how KASLR can currently be bypassed and will continue to be bypassed. Yet none of this is giving anyone any pause. Update: shortly after this post, yet another kernel infoleak was posted. This particular one has been fixed already in grsecurity the same way since August of 2012.
Kees Cook posted about the security features new to Linux 4.6 that the Linux Foundation is making such a big deal out of: https://plus.google.com/u/0/+KeesCook/posts/adtf8msMKNL. Through an outlandish amount of effort, KASLR support was added to ARM64 (https://lwn.net/Articles/673598/) where it will serve no effective purpose, much like the touted SSP support in the kernel from years ago. The "memory protection enabled by default" items are simply single-line changes to Kconfig defaults -- no new protections were added. Any sensible distribution or user would already have had these enabled. The only remaining item is the __ro_after_init item already discussed.
What can we look forward to in upstream's 4.7 and 4.8? In the Linux.com article Greg talks about the companies doing Linux kernel security work:
Kees' post shows us what all this effort will amount to (if it all lands) around the one year anniversary of the Kernel Self-Protection Project: more KASLR, a fully copy+pasted version of my RANDSTRUCT plugin (I have doubts this will land), and the GCC plugin infrastructure we've had in grsecurity for many years now. This latter improvement is being done by our own Emese Revfy under a CII grant. For all the talk of the "lot of work" of Google, Red Hat, and Intel, so far it's been nothing more than just talk. But as the Linux Foundation is a self-interested trade association, not a charity organization, clearly it wants to push the false message that its members are at the forefront of Linux security.
Don't be fooled by pleasant-sounding PR spin, the details matter. Companies and users interested in real security for the Linux kernel have been using grsecurity for years and will continue to do so. If you haven't had the opportunity yet, check out our recently published FAQ on RAP at https://grsecurity.net/rap_faq.php. RAP is the strongest and most efficient defense available anywhere today against code reuse attacks.
Until next time,
-Brad
In response to the question "What is the hard truth about Linux kernel security that many people don’t want to hear?" Greg KH mentions how Linux users need to be running the latest kernels, citing as evidence a specific "infamous" TTY vulnerability. Presumably this vulnerability was not this one for which an exploit was released within a week of publication of the vulnerability and affected the latest kernels at the time as well as those for the previous five years. To date, no exploit for that vulnerability has ever been released that would work against a kernel secured with grsecurity.
In describing this vulnerability, Greg says:
Three years later, somebody realized, ‘Hey! I can use this and get root!’ All of a sudden, this bug that we have fixed years ago had to be backported to really old enterprise kernels, because if you're running those, all of a sudden you had a root, you had to exploit those a long time.
As best I've been able to tell, the details of this "infamous" vulnerability have taken on new life through a fish tale. What Greg seems to be referring to is this vulnerability (CVE-2015-4170), which for most people wasn't memorable at all, and perhaps only "infamous" because of Greg's response to it, decrying the assignment of CVEs for vulnerabilities that have been implicitly fixed in newer upstream kernels. From that same thread we can see that all the claims in the quote are false. The bug couldn't have been used to get root, it caused a DoS-only deadlock (discovered by running a reproducer for the other vulnerability I mentioned above). The 2 years in the fish tale also suddenly became 3 years.
The real "hard truth" about Linux kernel security is that there's no such thing as a free lunch. Keeping up to date on the latest upstream kernel will generally net all the bug fixes that have been created thus far, but with it of course brings completely new features, new code, new bugs, and new attack surface. The majority of vulnerabilities in the Linux kernel are ones that have been released just recently, something any honest person active in kernel development can attest to. I commented as such back in 2010 on an LWN article about whether kernel vulnerabilities were old or new: https://lwn.net/Articles/410674/. I had claimed at the time that the methodology used in the post, which showed that vulnerabilities lasted on average 5 years before being discovered, had been biased in its conclusions by only relying on CVE statistics. As I noted in the comment, it was common practice at the time (though it seems to have improved slightly since) that when reporting a recent vulnerability on oss-sec, Red Hat wouldn't request a CVE as it didn't affect any of their distribution kernels, and none would subsequently be allocated. Comments in reply to that post from Dan Carpenter and others discuss the many other vulnerabilities found that weren't assigned CVEs.
We just saw an example of new changes introducing vulnerabilities recently with eBPF as noted in our previous blog post. The use-after-free vulnerability in eBPF which just recently was allowed to be accessed by unprivileged users, had a published exploit within a week of the bug's public disclosure: https://bugs.chromium.org/p/project-zero/issues/detail?id=808. Again, grsecurity was unaffected by this vulnerability. Add to this the hopefully now well-known plethora of vulnerabilities plaguing the introduction of unprivileged user namespaces.
So the real "hard truth" is that Linux is just now starting to play catch-up in the game of kernel self-protection that we've been playing for 13 years. Finally perhaps they've gotten the message that relying on updates alone doesn't provide any security, even against the least skilled attacker. You're always one 0day away from complete system compromise using the same old techniques that are known and dead in grsecurity for years. For all the talk of raising attacker cost, what's the cost to an attacker that downloads a fully-functional public exploit? Real security defenses make exploitation impossible for relevant bug classes and exploit vectors, and force attacks to more difficult unpublished techniques that are more time-consuming, harder to automate, and harder to perfect in an attacker's test environment.
Later in the article where Greg talks about how companies and users need to use the latest releases so that they get not only the most bugfixes, but also the newest security features, he says:
The new release that's going to come out next week has write-only protection to all the data structures. If something happens and you can't override a data structure, you can't. All of a sudden we took out a whole class of exploits that a bug could turn into an exploit.
On its face, this quote is utter nonsense -- hopefully only terribly misconstrued from Greg's supposed words (maybe the interview was over phone and transcribed poorly -- override vs overwrite etc). Ignoring all that, what Greg appears to be referring to is the addition of __ro_after_init, a renamed implementation of what in grsecurity and PaX we've had and called __read_only for the past 8 years. The idea of the feature is to make certain global kernel variables and data-structures read-only after they've been initialized by early kernel init code, protecting them against direct modification at runtime. A quick grep through our latest patch shows we're using this marking on about 200 global variables and data structures important to the kernel's security. In the to-be-released Linux 4.6, this feature protects exactly *one* thing, as a common theme seen in upstream security, the bare minimum effort required to claim support for X and publish an entire PR piece about it. Of course, in cherry-picking a tiny subset of a tiny feature in grsecurity, they fail to mention what it doesn't cover: that it doesn't have support for marking in modules like we do, nor does it allow to mark the many things we do which need to be written after init, but infrequently enough that we are able to make them ambiently read-only.
As seen with other upstream security features, once that claim of support for X is made, little is done to improve it or fix fundamental weaknesses. KASLR, a failed security mitigation introduced in Linux 3.14, continues to be as irrelevant as ever. Just in the past week a half dozen or so stack-based information leaks were published by academics at Georgia Tech, each one a KASLR defeat. The attacks published in academic literature (mentioned in our KASLR blog post prior to the addition of KASLR to Linux) still work today as a generic bypass. While work continues (currently on its 8th revision) on "improving" KASLR, the improvements are all completely orthogonal to how KASLR can currently be bypassed and will continue to be bypassed. Yet none of this is giving anyone any pause. Update: shortly after this post, yet another kernel infoleak was posted. This particular one has been fixed already in grsecurity the same way since August of 2012.
Kees Cook posted about the security features new to Linux 4.6 that the Linux Foundation is making such a big deal out of: https://plus.google.com/u/0/+KeesCook/posts/adtf8msMKNL. Through an outlandish amount of effort, KASLR support was added to ARM64 (https://lwn.net/Articles/673598/) where it will serve no effective purpose, much like the touted SSP support in the kernel from years ago. The "memory protection enabled by default" items are simply single-line changes to Kconfig defaults -- no new protections were added. Any sensible distribution or user would already have had these enabled. The only remaining item is the __ro_after_init item already discussed.
What can we look forward to in upstream's 4.7 and 4.8? In the Linux.com article Greg talks about the companies doing Linux kernel security work:
[W]e've been going through and doing a lot of work. We have people working on a lot of things: taking bits and pieces of the GRSec [sic], the large security patch set, taking them and merging them into the kernel as needed and doing some other work. CII is helping fund that. A number of the developers working on that are just being funded by the companies that they work for such as Google, Red Hat and Intel. They are doing a lot of work to improve kernel security.
Kees' post shows us what all this effort will amount to (if it all lands) around the one year anniversary of the Kernel Self-Protection Project: more KASLR, a fully copy+pasted version of my RANDSTRUCT plugin (I have doubts this will land), and the GCC plugin infrastructure we've had in grsecurity for many years now. This latter improvement is being done by our own Emese Revfy under a CII grant. For all the talk of the "lot of work" of Google, Red Hat, and Intel, so far it's been nothing more than just talk. But as the Linux Foundation is a self-interested trade association, not a charity organization, clearly it wants to push the false message that its members are at the forefront of Linux security.
Don't be fooled by pleasant-sounding PR spin, the details matter. Companies and users interested in real security for the Linux kernel have been using grsecurity for years and will continue to do so. If you haven't had the opportunity yet, check out our recently published FAQ on RAP at https://grsecurity.net/rap_faq.php. RAP is the strongest and most efficient defense available anywhere today against code reuse attacks.
Until next time,
-Brad