Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RIP ROP: CET Internals in Windows 20H1

windows-internals.com

Post reply on HN
Print view View original

11–20 of 42 posts

Re: RIP ROP: CET Internals in Windows 20H1

#11

Post by barrkel »

OminousWeapons wrote: post #8
dg246 wrote: post #6

Earlier quoted context omitted.

ROP does not bypass ASLR or canaries. It does bypass DEP/NX in the sense that it executes code that already exists in executable memory.

Agree re: canaries, but when I learned about ROP I was told that ASLR typically is not employed on the text segment (due to lack of position independence) which is why ROP effectively acts a bypass for ASLR on the stack / heap and why we need things like control flow enforcement. Is this not the case or no longer the case?

Windows uses relocations, not PIC, to enable different load addresses. That means the image in memory has its self references patched by adding the difference between compiled in load address and runtime load address. System DLLs can still share code with one another as long as they share the same load address in different processes for that reboot of the operating system.

Historically EXEs were either linked without relocations or had relocations stripped. They were always loaded first so ended up where they wanted, no relocation necessary. But /dynamicbase flag to linker opts in to setting a bit in the PE header and retaining relocations, so the EXE can be loaded elsewhere.

TL;DR: Windows supports ASLR on both executables and dynamic libraries.

Re: RIP ROP: CET Internals in Windows 20H1

#12

Post by barrkel »

loeg wrote: post #10
OminousWeapons wrote: post #8

Earlier quoted context omitted.

Agree re: canaries, but when I learned about ROP I was told that ASLR typically is not employed on the text segment (due to lack of position independence) which is why ROP effectively acts a bypass for ASLR on the stack / heap and why we need things like control flow enforcement. Is this not the case or no longer the case?

ASLRing text segments is optional, but possible. There are negative performance tradeoffs.

There are limitations in sharing text segments in different processes, and extra memory usage mapping in text segments so relocations can be, uh, relocated, but once running there is no additional performance overhead. The runtime image is effectively "self-modified code" by the OS loader, patched to final addresses. No PIC register, no indirect references.

Re: RIP ROP: CET Internals in Windows 20H1

#13

Post by codys »

jnwatson wrote: post #9
staticassertion wrote: post #3

Earlier quoted context omitted.

It's a mitigation for a software exploitation technique called Return Oriented Programming (ROP). The mitigation is referred to as 'Control Flow Integrity' (CFI). https://software.intel.com/content/www/us/en/develop/article... Essentially an attacker who has the ability to exploit the first stage of a vulnerability will be able to stitch together "gadgets" from the program to build up a second stage of the exploit. C…

I'll add on since this is the most informative post so far (and I've written a static binary re-writer to add shadow stack protection to an existing binary). A shadow stack is a limited subset of the call stack that only stores return addresses. In normal operation, Every time your compiled program makes a function call, it stores the return address on the main call stack (modulo certain compiler optimizations) so th…

Can you provide some details on your binary rewriter to add shadow stack support? Was this a pure software approach, or was it designed to take advantage of the support in new intel microprocessors? Do you have a write up of or can you give a quick overview of your methodology? Is the source code published somewhere?

Re: RIP ROP: CET Internals in Windows 20H1

#14

Post by staticassertion »

jnwatson wrote: post #9
staticassertion wrote: post #3

Earlier quoted context omitted.

It's a mitigation for a software exploitation technique called Return Oriented Programming (ROP). The mitigation is referred to as 'Control Flow Integrity' (CFI). https://software.intel.com/content/www/us/en/develop/article... Essentially an attacker who has the ability to exploit the first stage of a vulnerability will be able to stitch together "gadgets" from the program to build up a second stage of the exploit. C…

I'll add on since this is the most informative post so far (and I've written a static binary re-writer to add shadow stack protection to an existing binary). A shadow stack is a limited subset of the call stack that only stores return addresses. In normal operation, Every time your compiled program makes a function call, it stores the return address on the main call stack (modulo certain compiler optimizations) so th…

Oh yeah, I completely glossed over the whole shadow/safestack mitigation. Thanks.

Re: RIP ROP: CET Internals in Windows 20H1

#16

Post by archgoon »

OminousWeapons wrote: post #8
dg246 wrote: post #6

Earlier quoted context omitted.

ROP does not bypass ASLR or canaries. It does bypass DEP/NX in the sense that it executes code that already exists in executable memory.

Agree re: canaries, but when I learned about ROP I was told that ASLR typically is not employed on the text segment (due to lack of position independence) which is why ROP effectively acts a bypass for ASLR on the stack / heap and why we need things like control flow enforcement. Is this not the case or no longer the case?

Gcc these days compiles with -pie (Position Independent Executable) by default. This makes the text section position independent and able to be relocated, like a shared library.

You are correct that the main TEXT section used to typically not be position independent.

Re: RIP ROP: CET Internals in Windows 20H1

#17

Post by schoen »

We've been through several generations of exploit mitigations starting with non-executable stacks, and, impressively, exploit developers found workarounds for each of them (although often the particular workarounds have requirements that might not be met in a particular vulnerability environment). In many cases I had the impression that the workarounds were surprising to the mitigation developers because the latter had expressed a lot of confidence that software security was about to make a huge leap and memory safety violations would rarely be exploitable anymore.

What are the prospects for finding workarounds to CET too?

(I don't mean to argue that there's no benefit to these mitigations or that some of them might not eventually finally stop whole classes of vulnerabilities. But I feel like their track record is not nearly as awesome as their inventors anticipated, so I wonder what informed opinion is on the eventual relevance or irrelevance of this one. Notably, the "RIP ROP" seems like a somewhat ambitious claim to mitigate a large amount of attack potential; how well-justified is it?)

Re: RIP ROP: CET Internals in Windows 20H1

#18

Post by muricula »

WrathOfJay wrote: post #15

And how about performance impact? The mitigation's that have been done in software recently came with an ugly performance cost (just not as ugly as the vulnerability). Is there any speculation about what this is going to cost?

I haven't read the whole paper, but this has a section on performance and a security analysis of the hardware feature: https://sci-hub.tw/10.1145/3337167.3337175

CET has two parts, a forwards edge protection (indirect jumps and calls like those necessary to execute a C++ virtual function, a Go interface function, or a Rust trait function), and a backwards edge protection to protect against Return Oriented Programming (overwriting the return address to attacker chosen code).

If I recall correctly, Windows will only use the backwards edge protection, since they already have a superior technology for forwards edge protection (CFG and XFG). The backwards edge protection has an impact of 1.65% according to that paper. Forwards edge protection had no impact.

I have to say, this is well worth it.

Re: RIP ROP: CET Internals in Windows 20H1

#19

Post by muricula »

schoen wrote: post #17

We've been through several generations of exploit mitigations starting with non-executable stacks, and, impressively, exploit developers found workarounds for each of them (although often the particular workarounds have requirements that might not be met in a particular vulnerability environment). In many cases I had the impression that the workarounds were surprising to the mitigation developers because the latter h…

There will probably be defeats and accidental gadgets for the first couple releases, but this hardware technology has the potential to be better than any software based mitigation with the same goals. Here's a paper with a more detailed security analysis: https://sci-hub.tw/10.1145/3337167.3337175
Post reply on HN