Understanding Hardware-Enforced Stack Protection

栏目: IT技术 · 发布时间: 4年前

内容简介:We aim to make Windows 10 one of the most secure operating systems for our customers and to do that we are investing in a multitude of security features. Our philosophy is to build features that mitigate broad classes of vulnerabilities, ideally without ha

We aim to make Windows 10 one of the most secure operating systems for our customers and to do that we are investing in a multitude of security features. Our philosophy is to build features that mitigate broad classes of vulnerabilities, ideally without having the app change its code. In other words, getting an updated version of Windows 10 should make the customer and the app safer to use. This comprehensiveMSDN document shows all of the security focused technologies we have built into Windows over the years and how it keeps our customers safe. Here is another presentation by Matt Miller and David Weston that goes deeper into our security philosophy for further reading.

We are now exploring security features with deep hardware integration to further raise the bar against attacks. By integrating Windows and its kernel deeply with hardware, we make it difficult and expensive for attackers to mount large scale attacks.

ROP (Return Oriented Programming) based control flow attacks have become a common form of attack based on our own and the external research community’s investigations ( Evolution of CFI attacks , Joe Bialek). Hence, they are the next logical point of focus for proactive, built-in Windows security mitigation technologies. In this post, we will describe our efforts to harden control flow integrity in Windows 10 through Hardware-enforced stack protection .

Memory safety vulnerabilities

The most common class of vulnerability found in systems software is memory safety vulnerabilities. This class includes buffer overruns, dangling pointers, uninitialized variables, and others.

A canonical example of a stack buffer overrun is copying data from one buffer to another without bound checking (i.e. strcpy). If an attacker replaces the data and size from the source buffer, the destination buffer and other important components of the stack can be corrupted (i.e. return addresses) to point to attacker desired code.

Understanding Hardware-Enforced Stack Protection

Dangling pointers occur when memory referenced by a pointer is de-allocated but a pointer to that memory still exists. In use-after-free exploits, the attacker can read/write through the dangling pointer that now points to memory the programmer did not intend to.

Uninitialized variables exist in some languages where variables can be declared without value, memory in this case is initialized with junk data. If an attacker can read or write to these contents, this will also lead to unintended program behavior.

These are popular techniques attackers can utilize to gain control and run arbitrary native code on target machines.

Arbitrary Code Execution

We frame our strategy for mitigating arbitrary code execution in the form of four pillars:

Understanding Hardware-Enforced Stack Protection

Code Integrity Guard (CIG) prevents arbitrary code generation by enforcing signature requirements for loading binaries.

Arbitrary Code Guard (ACG) ensures signed pages are immutable and dynamic code cannot be generated, thus guaranteeing the integrity of binaries loaded.

With the introduction of CIG/ACG, attackers increasingly resort to control flow hijacking via indirect calls and returns, known as call/jump oriented programming (COP/JOP) and return oriented programming (ROP).

We shipped Control Flow Guard (CFG) in Windows 10 to enforce integrity on indirect calls (forward-edge CFI). Hardware-enforced Stack Protection will enforce integrity on return addresses on the stack (backward-edge CFI), via Shadow Stacks.

The ROP problem

In systems software, if an attacker finds a memory safety vulnerability in code, the return address can be hijacked to target an attacker defined address. It is difficult from here to directly execute a malicious payload in Windows thanks to existing mitigations including Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) , but control can be transferred to snippets of code (gadgets) in executable memory. Attackers can find gadgets that end with the RET instruction (or other branches), and chain multiple gadgets to perform a malicious action (turn off a mitigation), with the end goal of running arbitrary native code.

Understanding Hardware-Enforced Stack Protection

Hardware-enforced stack protection in Windows 10

Keep in mind, Hardware-enforced stack protection will only work on chipsets with Intel’s Control-flow Enforcement Technology (CET) instructions. Here is an Intel whitepaper with more information on CET.

In this post, we will describe only the relevant parts of the Windows 10 implementation. This technology provides parity with program call stacks, by keeping a record of all the return addresses via a Shadow Stack. On every CALL instruction, return addresses are pushed onto both the call stack and shadow stack, and on RET instructions, a comparison is made to ensure integrity is not compromised.

If the addresses do not match, the processor issues a control protection (#CP) exception. This traps into the kernel and we terminate the process to guarantee security.

Understanding Hardware-Enforced Stack Protection

Shadow stacks store only return addresses, which helps minimize the additional memory overhead.

Control-flow Enforcement Technology (CET) Shadow Stacks

Shadow stack compliant hardware provides extensions to the architecture by adding instructions to manage shadow stacks and hardware protection of shadow stack pages.

Hardware will have a new register SSP, which holds the S hadow S tack P ointer address. The hardware will also have page table extensions to identify shadow stack pages and protect those pages against attacks.

New instructions are added for management of shadow stack pages, including:

  • INCSSP – increment SSP (i.e. to unwind shadow stack)
  • RDSSP – read SSP into general purpose register
  • SAVEPREVSSP/RSTORSSP – save/restore shadow stack (i.e. thread switching)

The full hardware implementation is documented in Intel’s CET manual .

Compiling for Hardware-enforced Stack Protection

In order to receive Hardware-enforced stack protection on your application, there is anew linker flag which sets a bit in the PE header to request protection from the kernel for the executable.

If the application sets this bit and is running on a supported Windows build and shadow stack-compliant hardware, the Kernel will maintain shadow stacks throughout the runtime of the program. If your Windows version or the hardware does not support shadow stacks, then the PE bit is ignored.

By making this an opt-in feature of Windows, we are allowing developers to first validate and test their app with hardware-enforced stack protection, before releasing their app.

Hardware-enforced Stack Protection feature is under development and an early preview is available in Windows 10 Insider previews builds (fast ring) . If you have Intel CET capable hardware, you can enable the above linker flag on your application to test with the latest Windows 10 insider builds.

Conclusion

Hardware-enforced Stack Protection offers robust protection against ROP exploits since it maintains a record of the intended execution flow of a program. To ensure smooth ecosystem adoption and application compatibility, Windows will offer this protection as an opt-in model, so developers can receive this protection, at your own pace.

We will provide ongoing guidance on how to re-build your application to be shadow stacks compliant. In our next post, we will dig deeper into best practices, as well as provide technical documentation. This protection will be a major step forward in our continuous efforts to make Windows 10 one of the most secure operating system for our customers.

Kernel protection team - Jin Lin, Jason Lin, Niraj Majmudar and Greg Colombo


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

代码本色:用编程模拟自然系统

代码本色:用编程模拟自然系统

Daniel Shiffman / 周晗彬 / 人民邮电出版社 / 2014-10 / 99.00元

本书介绍了用计算机模拟自然系统涉及的编程策略与技术,涵盖了基本的数学和物理概念,以及可视化地展示模拟结果所需的高级算法。读者将从构建基本的物理引擎开始,一步一步地学习如何创建智能移动的物体和复杂的系统,为进一步探索生成设计奠定基础。相关的知识点包括力、三角、分形、细胞自动机、自组织和遗传算法。本书的示例使用基于Java的开源语言及开发环境Processing编写。本书网站http://www.na......一起来看看 《代码本色:用编程模拟自然系统》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

html转js在线工具
html转js在线工具

html转js在线工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具