OpenBSD gets RETGUARD (anti-ROP) for Clang x64

RETGUARD for clang (amd64) added to -current

Contributed by rueda on 2018-06-06 from the d(e)ropping-the-gadgets dept.

Todd Mortimer has committed “RETGUARD” for clang (for amd64).;sid=20180606064444

Intel adds ROP-detection Branch Monitoring support to Linux

Date: Fri, 3 Nov 2017 11:00:03 -0700

This patchset adds support for Intel’s branch monitoring feature. This feature uses heuristics to detect the occurrence of an ROP(Return Oriented Programming) or ROP like(JOP: Jump oriented programming) attack. These heuristics are based off certain performance monitoring statistics, measured dynamically over a short configurable window period. ROP is a malware trend in which the attacker can compromise a return pointer held on the stack to redirect execution to a different desired instruction. Currently, only the Cannonlake family of Intel processors support this feature. This feature is enabled by CONFIG_PERF_EVENTS_INTEL_BM. Once the kernel is compiled with CONFIG_PERF_EVENTS_INTEL_BM=y on a Cannonlake system, the following perf events are added which can be viewed with perf list:
intel_bm/branch-misp/ [Kernel PMU event]
intel_bm/call-ret/ [Kernel PMU event]
intel_bm/far-branch/ [Kernel PMU event]
intel_bm/indirect-branch-misp/ [Kernel PMU event]
intel_bm/ret-misp/ [Kernel PMU event]
intel_bm/rets/ [Kernel PMU event]

A perf-based kernel driver has been used to monitor the occurrence of one of the 6 branch monitoring events. There are 2 counters that each can select between one of these events for evaluation over a specified instruction window size (0 to 1023). For each counter, a threshold value (0 to 127) can be configured to set a point at which an interrupt is generated. The entire system can monitor a maximum of 2 events(either from the same or different tasks) at any given time. Apart from the kernel driver, this patchset adds CPUID of Cannonlake processors to Intel family list and the Documentation/x86/intel_bm.txt file with some information about Intel Branch monitoring.

Microsoft MEX Windbg extension

Microsoft recently released a new Windows Windbg debugger extension called MEX. It has a variety of features, dozens of commands for many of Microsoft’s products. It appears to have been removed from the download site for a while, but it is up now, at least for the moment.


There’s a copy of the MEX help usage listed here:


a bit more on Intel CET

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.

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.

Intel CET

Intel release new technology specifications to protect against ROP attacks
By Baiju Patel on June 9, 2016    

“Intel has a long history of working with the software community and making strides in strengthening protections of operating systems and software running on modern computer systems. As these protections came into effect, adversaries started looking for creative alternatives to bypass these protections, Return Oriented Programming (also known as ROP) and Jump Oriented Programming (also known JOP) are two such techniques that has been gaining popularity. ROP or JOP attacks are particularly hard to detect or prevent because the attacker uses existing code running from executable memory in a creative way to change program behavior. What makes it hard to detect or prevent ROP/JOP is the fact that attacker uses existing code running from executable memory. Many software-based detection and prevention techniques have been developed and deployed with limited success.

Intel and Microsoft recognized the seriousness of ROP attacks as well as the difficulty in developing the means to protect from ROP/JOP. Together, we considered over ten technology innovations to address these emerging threats over last 7 years and narrowed it down to the CET specification for x86/x64 architecture to make significant advances in addressing the ROP threat. Based on prior experience with defining instruction set extensions, and enabling challenges associated with a new ISA, we set goals to have an ISA for ROP/JOP prevention that is transparent to most well designed/implemented software requiring minimal to no changes; yet allow opt out capability for SW that requires changes. We also wanted to make sure that the solution is applicable to not just applications, but also to operating system kernels, and is beneficial to SW written using most programming languages. We also wanted to ensure that software enabled for CET works on legacy platforms without changes (albeit with no security benefits). Finally, and most importantly, we wanted to address all known ROP/JOP attacks.

While we include a brief description of CET here, there is no substitute for careful reading of the complete specification.  Here we highlight two key aspects of ISA to get you started, namely, shadow stack and indirect branch tracking. It is the combination of these two that are designed to address both ROP and JOP class of attacks. […]”


ROPMEMU is a framework to analyze, dissect and decompile complex code-reuse attacks. It adopts a set of different techniques to analyze ROP chains and reconstruct their equivalent code in a form that can be analyzed by traditional reverse engineering tools. In particular, it is based on memory forensics (as its input is a physical memory dump), code emulation (to faithfully rebuild the original ROP chain), multi-path execution (to extract the ROP chain payload), CFG recovery (to rebuild the original control flow), and a number of compiler transformations (to simplify the final instructions of the ROP chain). Specifically, the memory forensics part is based on Volatility plugins. The emulation and the multi-path part is implemented through the Unicorn emulator. […]



“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.” […]