Retguard: An improved stack protector for OpenBSD

#1

Post by brynet » Wed, Jun 06, 2018, 12:39 PM UTC

Retguard: An improved stack protector for OpenBSD
marc.info

Re: Retguard: An improved stack protector for OpenBSD

#2

Post by trillic » Wed, Jun 06, 2018, 1:00 PM UTC

How is this different than any other stack canary? Is it because it is per-function instead of per-stack like Linux?

Re: Retguard: An improved stack protector for OpenBSD

#3

Post by brynet » Wed, Jun 06, 2018, 1:05 PM UTC

trillic wrote: post #2

How is this different than any other stack canary? Is it because it is per-function instead of per-stack like Linux?

This uses OpenBSD's random-data memory [0][1] feature, which was used by the stack protector to provide per shared object cookies.

RETGUARD is more than just an improved stack protector, as explained in the commit message it protects function epilogues that are close to return instructions.

[0] https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib...

[1] https://www.openbsd.org/innovations.html

Re: Retguard: An improved stack protector for OpenBSD

#4

Post by brynet » Wed, Jun 06, 2018, 1:12 PM UTC

It's also worth mentioning there's previous work to reduce the amount of polymorphic gadgets in the instruction stream, including a new framework for clang:

https://marc.info/?l=openbsd-cvs&m=151123332419798&w=2

https://marc.info/?l=openbsd-cvs&m=152495643720502&w=2

Re: Retguard: An improved stack protector for OpenBSD

#5

Post by brandmeyer » Wed, Jun 06, 2018, 1:15 PM UTC

trillic wrote: post #2

How is this different than any other stack canary? Is it because it is per-function instead of per-stack like Linux?

First off, the normal glibc/GCC stack canary is per-process, not per-stack.

(I started writing a more detailed reply based on the commit description, but there was too much speculation without seeing their source code).

Re: Retguard: An improved stack protector for OpenBSD

#6

Post by [deleted] » Wed, Jun 06, 2018, 1:16 PM UTC

[deleted]

Re: Retguard: An improved stack protector for OpenBSD

#7

Post by brynet » Wed, Jun 06, 2018, 1:19 PM UTC

brandmeyer wrote: post #5

trillic wrote: post #2

How is this different than any other stack canary? Is it because it is per-function instead of per-stack like Linux?

First off, the normal glibc/GCC stack canary is per-process, not per-stack. (I started writing a more detailed reply based on the commit description, but there was too much speculation without seeing their source code).

OpenBSD's is per shared library, i.e: libc has a different stack cookie than your application and/or other libraries.

RETGUARD however, is per function.

Re: Retguard: An improved stack protector for OpenBSD

#8

Post by brynet » Wed, Jun 06, 2018, 1:21 PM UTC

[deleted] wrote: post #6

[deleted]

This is not a dupe! That is a previous incarnation of RETGUARD that wasn't committed. The implementations are very different, please undo.

Re: Retguard: An improved stack protector for OpenBSD

#9

Post by [deleted] » Wed, Jun 06, 2018, 1:39 PM UTC

[deleted]

Re: Retguard: An improved stack protector for OpenBSD

#10

Post by rurban » Wed, Jun 06, 2018, 2:00 PM UTC

Anyone seen this new ReturnProtectorPass also upstream at clang? It was written end of 2017 AFAIR, that when when we last discussed this here.

CFI still looks more promising to me though. Protecting the CALL part. But this is better than the old gcc/clang stack cookie of course, protecting RET.