[…]Respectre(TM) is a nod to the Spectre speculation attack and signifies that it (re)veals potential Spectre vulnerabilities, (re)spects the original intent of the code, and automatically (re)factors it via a compiler plugin to eliminate speculation-based side channels. All plugin-capable versions of the compiler commonly used to compile Linux are supported, and the plugin itself is architecture-independent. The initial release to grsecurity(R) customers focusing on Spectre v1 supports the ARMv7, AArch64, PPC64, x86, and x86_64 architectures. Special care was taken in designing the plugin to ensure both low impact to compilation time as well as negligible impact to runtime performance (measured as 0.3% in a kernel-focused stress test). The plugin incorporates advanced static analysis far beyond the level of any existing tools for any OS, and is the 4th largest plugin of the 14 available in the grsecurity(R) kernel patches. Work is already underway to enhance the static analysis of the plugin even further and add coverage for other similar Spectre types.[…]
Tag: grsecurity
Automated Detection, Exploitation, and Elimination of Double-Fetch Bugs using Modern CPU Features
Double-fetch bugs are a special type of race condition, where an unprivileged execution thread is able to change a memory location between the time-of-check and time-of-use of a privileged execution thread. If an unprivileged attacker changes the value at the right time, the privileged operation becomes inconsistent, leading to a change in control flow, and thus an escalation of privileges for the attacker. More severely, such double-fetch bugs can be introduced by the compiler, entirely invisible on the source-code level. We propose novel techniques to efficiently detect, exploit, and eliminate double-fetch bugs. We demonstrate the first combination of state-of-the-art cache attacks with kernel-fuzzing techniques to allow fully automated identification of double fetches. We demonstrate the first fully automated reliable detection and exploitation of double-fetch bugs, making manual analysis as in previous work superfluous. We show that cache-based triggers outperform state-of-the-art exploitation techniques significantly, leading to an exploitation success rate of up to 97%. Our modified fuzzer automatically detects double fetches and automatically narrows down this candidate set for double-fetch bugs to the exploitable ones. We present the first generic technique based on hardware transactional memory, to eliminate double-fetch bugs in a fully automated and transparent manner. We extend defensive programming techniques by retrofitting arbitrary code with automated double-fetch prevention, both in trusted execution environments as well as in syscalls, with a performance overhead below 1%.
GRsecurity drops 0day
GRSecurity sues Bruce Perens over GPL issues
Below Register article has a link to the PDF of the court case.
Posted on June 28, 2017 by Bruce
Warning: Grsecurity: Potential contributory infringement and breach of contract risk for customers
It’s my strong opinion that your company should avoid the Grsecurity product sold at grsecurity.net because it presents a contributory infringement and breach of contract risk.[…]
[…]Defendant is a computer programmer, known for his creation of the Open Source Definition and co-founder of the Open Source Initiative. This action arises from Defendants’ abusive and false claims made on a blog post 1 (“Posting”), on Defendant’s website, http://www.perens.com (the “Website”), regarding Plaintiff’s business, which has resulted in substantial harm to Plaintiff’s reputation, goodwill, and future business prospects.[…]
a bit more on Intel CET
http://blogs.intel.com/evangelists/2016/06/09/intel-innovating-stop-cyber-attacks/
https://forums.grsecurity.net/viewtopic.php?f=7&t=4490
The GRSecurity post has a few more links as well:
[…]
Full disclosure: we have a competing production-ready solution to defend against code reuse attacks called RAP, see [R1], [R2]. RAP isn’t tied to any particular CPU architecture or operating system, and it scales to real-life software from Xen to Linux to Chromium with excellent performance.
[…]
Conclusion
In summary, Intel’s CET is mainly a hardware implementation of Microsoft’s weak CFI implementation with the addition of a shadow stack. Its use will require the presence of Intel processors that aren’t expected to be released for several years. Rather than truly innovating and advancing the state of the art in performance and security guarantees as RAP has, CET merely cements into hardware existing technology known and bypassed by academia and industry that is too weak to protect against the larger class of code reuse attacks. One can’t help but notice a striking similarity with Intel’s MPX, another software-dependent technology announced with great fanfare a few years ago that failed to live up to its many promises and never reached its intended adoption as the solution to end buffer overflow attacks and exists only as yet another bounds-checking based debugging technology.
GRsecurity on Linux kernel security
There’s an interesting post on the GRsecurity forums on the security of the Linux kernel:
RAP
“RAP is here. Public demo in 4.5 test patch and commercially available today! Today’s release of grsecurity® for the Linux 4.5 kernel marks an important milestone in the project’s history. It is the first kernel to contain RAP, a defense mechanism against code reuse attacks. RAP was announced to the world at the H2HC conference in October 2015 and represents the best available solution of its type. RAP is the result of our multi-years research and development in Control Flow Integrity (CFI) technologies by PaX. It ground-breakingly scales to C and C++ code bases of arbitrary sizes and provides best-effort protection against code reuse attacks with minimal performance impact. The public version of RAP available in the grsecurity test kernels from now on demonstrates a subset of the features in the full version, available today for commercial licensing from Open Source Security, Inc. The demo version will evolve over time, but is currently tailored for x64 kernel use only and does not support C++, link-time optimization, compile time static analysis, and probabilistic return address protection. In addition, the demo’s GPLv2 license excludes userland applications due to the GCC library runtime exception for GCC plugins.” […]
https://grsecurity.net/rap_announce.php
https://grsecurity.net/rap_faq.php
https://grsecurity.net/features.php
GRSecurity quits
https://twitter.com/grsecurity/status/626915991184932865
and:
https://twitter.com/grsecurity/status/636659374551777281
Today’s announcement:
https://grsecurity.net/announce.php
Excerpt:
“This announcement is our public statement that we’ve had enough. Companies in the embedded industry not playing by the same rules as every other company using our software violates users’ rights, misleads users and developers, and harms our ability to continue our work. Though I’ve only gone into depth in this announcement on the latest trademark violation against us, our experience with two GPL violations over the previous year have caused an incredible amount of frustration. These concerns are echoed by the complaints of many others about the treatment of the GPL by embedded Linux industry in particular over many years.”
DejaVu from 2004:
http://developers.slashdot.org/story/04/05/31/1949241/end-of-development-for-grsecurity-announced
“Beginning today, May 31, 2004, development of grsecurity will cease. On June 7, the website, forums, mailing list, and CVS will be shut down. Due to a sponsor unexpectedly dropping sponsorship of grsecurity while continually promising payment, I began the summer in debt and had to borrow money from family to pay for food. If none of the companies that depend on grsecurity, some of them being very large, are able to sponsor the project, grsecurity will cease to exist. I am not looking for paypal donations at this point, unless those that donate do so with the recognition that despite their donation, grsecurity may still never be returning.”
Things are not looking good for embedded Linux security today. I don’t know the backstories. I wonder what happens next?