Hacker News Reader

Comment by libeclipse | Hacker News Reader

With BTI can the attacker not just write a BTI opcode to the start of the jump location? Usually you would jump to a buffer that you control the contents of (i.e. shellcode)

View on HN

W^X prevents that straightforward attack, by not allowing writable buffers to be executed. The typical way to defeat W^X is ROP chains with gadgets consisting of pieces of code already present in the binary. BTI, in turn, is a defense against that.

It's very much a cat and mouse game.

So now we're going to see the next step be making gadgets out of code fragments that happen to begin with BTI.

The real end game here is memory safety.

No real end game I'm afraid.

Data-only attacks do exist (and are bound to become a lot more common).

End game for the class of remote code execution vulnerabilities.

That's where pointer authentication can help.

There are ways to compile that elide ROP gadgets. It's easier on architectures like ARM than x86. OpenBSD has taken this approach:

   Number of ROP gadgets in 6.3-release arm64 kernel
     69935
   Number of ROP gadgets in 6.4-beta arm64 kernel
     46

https://www.openbsd.org/papers/eurobsdcon2018-rop.pdf

Note: As described later in the presentation, those 46 remaining gadgets are in the boot code, which is erased after booting.

I'm not convinced that a conditional branch to the ret followed by breakpoints between it and the ret is enough to remove the usefulness of the gadget as much as they say.

Why?

It's exactly the kind of roadblock that people who do offensive security are great at finding loopholes around.

I mean, that's really been their job every time a new mitigation is developed…the introduction of NX led to the use of ROP, which has been joined by JOP techniques as efforts to remove return gadgets gain momentum.

This is more like fitting shellcode into something that can be strcpyed. Not really that much of a complication from an attack perspective.

I’m not convinced their search for ROP gadgets in libc is useful; often there’s a “magic” address that will do all the work to directly execve /bin/sh if you jump there (in glibc, this is inside of do_system).

> memory safety

Harvard Architecture?

Or a language that doesn't let you overflow buffers.

That hasn't been true in a very long time.

Reply on news.ycombinator.com