RIP ROP: CET Internals in Windows 20H1 • Hacker News Board

Re: RIP ROP: CET Internals in Windows 20H1

#21

Post by staticassertion » Wed, Jul 22, 2020, 12:06 AM UTC

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…

It's not totally true that attackers have found ways bypass mitigations. In many cases the attackers require entirely new capabilities, or separate vulnerabilities, to get around a mitigation. And in some cases it makes an attack statistically unlikely, even if it may succeed.

Lots of mitigations do suck, and are a huge waste of time and effort, but quite a few are very significant. It's very rare that a bypass is a surprised except when the mitigation is poorly thought out. Good mitigations start with a threat model.

An example is ASLR. Once in a while ASLR is pronounced 'dead' because an attacker with capabilities that ASLR does not try to defend against can bypass ASLR. For example, the attacker has arbitrary compute on the system with ASLR. No one who built ASLR was surprised by this.

Re: RIP ROP: CET Internals in Windows 20H1

#22

Post by loeg » Wed, Jul 22, 2020, 12:44 AM UTC

barrkel wrote: post #12

loeg wrote: post #10

Earlier quoted context omitted.

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.

Right. You've described the performance impact: a ton of relocations hurts startup time, and the modified memory reduces sharing, costing additional memory. If startup time does not matter and memory is free, sure, it has no costs.

Re: RIP ROP: CET Internals in Windows 20H1

#23

Post by jnwatson » Wed, Jul 22, 2020, 12:59 AM UTC

codys wrote: post #13

jnwatson wrote: post #9

Earlier quoted context omitted.

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?

No, it was proprietary code, and it wasn't for an Intel processor. It was a pure software approach, but the particular (embedded) environment made it harder to attack the shadow stack itself.

I had a pretty cool optimization that I don't think anyone's figured out yet. Oh well. That's the downside of software-as-trade-secrets.

Re: RIP ROP: CET Internals in Windows 20H1

#24

Post by barrkel » Wed, Jul 22, 2020, 1:43 AM UTC

loeg wrote: post #22

barrkel wrote: post #12

Earlier quoted context omitted.

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.

Right. You've described the performance impact: a ton of relocations hurts startup time, and the modified memory reduces sharing, costing additional memory. If startup time does not matter and memory is free, sure, it has no costs.

Yeah; a linear scan over what, possibly as many as a couple of megabytes. I bet that takes a while.

(Seriously? :-)

Re: RIP ROP: CET Internals in Windows 20H1

#25

Post by stellersjay » Wed, Jul 22, 2020, 2:42 AM UTC

Exploit devs love a good challenge. Each mitigation is another lessons learned :)

Re: RIP ROP: CET Internals in Windows 20H1

#26

Post by saagarjha » Wed, Jul 22, 2020, 3:18 AM UTC

staticassertion wrote: post #21

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…

It's not totally true that attackers have found ways bypass mitigations. In many cases the attackers require entirely new capabilities, or separate vulnerabilities, to get around a mitigation. And in some cases it makes an attack statistically unlikely, even if it may succeed. Lots of mitigations do suck, and are a huge waste of time and effort, but quite a few are very significant. It's very rare that a bypass is a…

It's kind of easy to say "ASLR is not resistant to infoleaks" but it's really quite another thing if the infoleak ends up coming from something like a microarchitectural sidechannel or even an undocumented proprietary processor extension, rather than "hurr durr here is a slid pointer, we hand out these out like candy".

Re: RIP ROP: CET Internals in Windows 20H1

#27

Post by saagarjha » Wed, Jul 22, 2020, 3:19 AM UTC

stellersjay wrote: post #25

Exploit devs love a good challenge. Each mitigation is another lessons learned :)

I would argue that the learning is circular, as exploit development learns from mitigations just as much as mitigation development is informed by exploits ;)

Re: RIP ROP: CET Internals in Windows 20H1

#28

Post by saagarjha » Wed, Jul 22, 2020, 3:21 AM UTC

archgoon wrote: post #16

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?

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.

Not only is the text segment relocatable, the entire binary is generally compiled as ET_DYN so it is a shared library in a sense.

Re: RIP ROP: CET Internals in Windows 20H1

#29

Post by saagarjha » Wed, Jul 22, 2020, 3:23 AM UTC

jnwatson wrote: post #23

codys wrote: post #13

Earlier quoted context omitted.

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?

No, it was proprietary code, and it wasn't for an Intel processor. It was a pure software approach, but the particular (embedded) environment made it harder to attack the shadow stack itself. I had a pretty cool optimization that I don't think anyone's figured out yet. Oh well. That's the downside of software-as-trade-secrets.

Can you name it, so we can find it ourselves? ;)

Re: RIP ROP: CET Internals in Windows 20H1

#30

Post by pabs3 » Wed, Jul 22, 2020, 3:45 AM UTC

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…

grsec seems to think CET won't be effective:

https://grsecurity.net/effectiveness_of_intel_cet_against_co...