8 ms·

Retguard: An improved stack protector for OpenBSD

187 points by brynet 8y ago

trillic 8y ago
How is this different than any other stack canary? Is it because it is per-function instead of per-stack like Linux?
- brynet 8y ago
  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/libexec/ld.so/SPECS.randomdata https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib... [1] https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html
- brandmeyer 8y ago
  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).
  - brynet 8y ago
    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.
brynet 8y ago
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=151123332419798&w=2 https://marc.info/?l=openbsd-cvs&m=152495643720502&w=2 https://marc.info/?l=openbsd-cvs&m=152495643720502&w=2
deleted 8y ago
[deleted]
- brynet 8y ago
  This is not a dupe! That is a previous incarnation of RETGUARD that wasn't committed. The implementations are very different, please undo.
deleted 8y ago
[deleted]
rurban 8y ago
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.
atonse 8y ago
While I didn't understand most of this, any reason why they're still using CVS? Genuinely curious, I'm sure they have good reasons.
- davisr 8y ago
  The developer makes the code, not the tools. Some people prefer tools different to others.
- brynet 8y ago
  You must be jealous that we're self-hosted. ;-)
  - kazinator 8y ago
    I made a program called Meta-CVS in 2002 that stores a versioned directory structure with permissions and symbolic links along with the files in an ordinary CVS repository. http://www.kylheku.com/~kaz/mcvs.html http://www.kylheku.com/~kaz/mcvs.html Meta-CVS has an import feature (mcvs grab) which detects renamed files. It fixes up symlinks pointing to moved files too and such. Meta-CVS didn't catch on widely because by the time I had it stable, CVS itself was being side tracked by newly emerging projects like SVN. Plus people were afraid of it being written in Common Lisp. If you're still using CVS in 2018 and not Meta-CVS, you're ridiculously backwards though. :)
    - nickpsecurity 8y ago
      The need to secure repos was identified by Karger in MULTICS evaluation. It was a requirement in TCSEC security certification. A great summary of issues is below by David A. Wheeler: https://www.dwheeler.com/essays/scm-security.html https://www.dwheeler.com/essays/scm-security.html On top of yours, the OpenCM and Aegis programs attempted to meet some of these requirements. Most ignore them. Big, blind spot in software security.
- busterarm 8y ago
  They've managed to maintain a consistent roughly-6 month release cadence since 1995. CVS is working for them, so why switch?
amenghra 8y ago
The post from ~9 months ago by deraadt is worth reading: https://marc.info/?l=openbsd-tech&m=150317547021396&w=2 https://marc.info/?l=openbsd-tech&m=150317547021396&w=2
- brynet 8y ago
  That is the previous design which changed significantly from what's been committed today (see other comments). Github mirror, for easier review: https://github.com/openbsd/src/commit/e688c2b0648a80551cf7353d9f455c7cbb98f13c https://github.com/openbsd/src/commit/e688c2b0648a80551cf735...
kernoble 8y ago
What's meant by the term "gadget"? Does it mean an exploit mechanism? My searches are mostly showing information about USB device drivers.
- deegles 8y ago
  It's a reference to this class of vulnerabilities: https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming
  - kernoble 8y ago
    Cool. Thanks!
- tptacek 8y ago
  In exploit development parlance, a gadget is a block of assembly instructions executed outside their intended order by an attacker-induced control transfer. A gadget might start in the middle of a basic block, for instance, and be invoked when an attacker uses a memory corruption vulnerability to overwrite a function pointer with an address they control. "Return oriented programming", which is kind of a dumb name, is the idea of harvesting gadgets from the text of a program and then using them as primitives for a new program. Gadgets are stitched together by the "return" instruction (hence the name ROP). When used by attackers this way, "ret" isn't really "returning" so much as it's being used as an arbitrary indirect jump mechanism.
mtgx 8y ago
Speaking of OpenBSD, does anyone know what happened here and how true it is? https://arstechnica.com/information-technology/2010/12/fbi-accused-of-planting-backdoor-in-openbsd-ipsec-stack/ https://arstechnica.com/information-technology/2010/12/fbi-a... It would certainly jive with John Gilmore's story on how the NSA worked through the standard bodies to keep IPSEC easily exploitable by making the design too difficult to implement properly: https://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html https://www.mail-archive.com/cryptography@metzdowd.com/msg12... Their behavior around Simon & Speck and how they refused to reveal details on how exploitable they could be also seems to be similar to their previous tactics. This is why it's worrisome that Google intends to implement Speck in Android and have pushed it to the Linux kernel, too. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da7a0ab5b4babbe5d7a46f852582be06a00a28f0 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... More details on how the NSA has been sabotaging open source projects here: https://www.youtube.com/watch?v=fwcl17Q0bpk https://www.youtube.com/watch?v=fwcl17Q0bpk
- admax88q 8y ago
  Don't have all my sources on hand, but the last time I looked in to this the general conclusion I came to was that there's evidence to suggest that someone was in fact paid to put vulnerabilities into the IPSec stack of OpenBSD. But there was no evidence to suggest that those vulnerabilities ever got written or if they were written that they ever made it into the source tree. I believe OpenBSD conducted an audit of their tree when rumours of an IPSec backdoor started and didn't find anything alarming.
  - sverige 8y ago
    Pretty ancient stuff to bring up, especially in this context. Here's the last denial I recall by one of the people accused of planting backdoors in OpenBSD. Note the date. https://www.itworld.com/article/2744922/open-source-tools/openbsd-fbi-allegations-denied-by-named-participants.html https://www.itworld.com/article/2744922/open-source-tools/op...
    - 8y ago
nneonneo 8y ago
Cool. If I understand the LLVM code correctly, it's inserting the following instruction sequence into the code: mov r11, [cookie] xor r11, [rsp] ... xor r11, [rsp] cmp r11, [cookie] jeq 2 int 3 int 3 ret (where r11 might be some other suitable temp register as needed). cookie points to an 8-byte chunk of .openbsd.randomdata, a section that is initialized at binary load time by the kernel to contain random data. The canary is one of 4000 possible values, named "__retguard_0" through "__retguard_3999", presumably to avoid having the kernel generate an unbounded amount of random data - the section is limited to 1MB in size. This makes ret instructions fairly hard to use for rop purposes. Unlike the original design, which xor'd [rsp] directly, this new approach preserves return prediction so it should have a lesser effect on performance. With the changes to reduce polymorphic gadgets in place, this should make ROP attacks significantly less palatable. Also, in the original design, an arbitrary leak made rop attacks feasible as you could just place xor-encrypted return addresses on the stack. With the new design, you need repeatable register control too, assuming the temp register isn't spilled, which raises the bar quite a bit.
- Annatar 8y ago
  What is preventing an attacker from overwriting the last xor and cmp instruction sequence with nop instructions?
  - ben_bai 8y ago
    W^X (W xor X) which means memory is either writeable or executable. Guess what, OpenBSD maps code only executable and not writeable.
Klasiaster 8y ago
The underlying assumption is that the XORd value cannot be crafted by the attacker. If read-access of [rsp] is possible, this scheme is vulnerable to information leak of the return address (or another program pointer which lets the attacker derive the return address), because cookie = retaddr^[rsp]. But still this is better than the original RETGUARD which was easier to attack in both ways, either a leak of the stack position to get the return address or vice versa.
tptacek 8y ago
I don't pay enough attention to know how this is different from what PaX team did with RAP 3 years ago: https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.p...
- ectospheno 8y ago
  They put it into a system people will actually use. Just leaving these here... https://www.theregister.co.uk/2017/06/26/linus_torvalds_slams_pure_garbage_from_clowns_at_grsecurity/ https://www.theregister.co.uk/2017/06/26/linus_torvalds_slam... https://www.theregister.co.uk/2018/01/19/grsecurity_libel_appeal/ https://www.theregister.co.uk/2018/01/19/grsecurity_libel_ap...
  - tptacek 8y ago
    This is just drama and isn't informative in any way.
    - justinjlynn 8y ago
      It's informative in that it tells one that one should stay away from grsec's patch sets and why. When the BDFL of one's kernel says something like that, combined with how radioactive the community interaction seems to have been in the past, the notion that one might get sufficient support or have positive interactions with the wider community while using the grsec kernel fork is dubious at best.
      - tptacek 8y ago
        The idea that you should avoid grsecurity because Linus Torvalds, the "BDFL", says so is so messed up I actually don't know how to rebut it. Either way: I'm not saying Retguard is based on RAP --- my question was, "what's the relationship between the techniques". But if there is a relationship, OpenBSD should be explicit about it, so that we can keep track of the evolution of memory corruption countermeasures. I do not care whether you think people should or shouldn't run grsecurity.
DeepYogurt 8y ago
Question; does this protection get applied to all languages that use llvm on openbsd or is it C/C++ specific?
keyle 8y ago
When I first read this, I thought how come no one thought of this before? It feels like common sense. Dumb question (potentially): will this make code that is not inlined, calling a function many times, often, run a lot slower?
- Mordak 8y ago
  It depends on the function. Many things will contribute. If your CPU can keep the cookie in cache then loading it repeatedly will relatively fast compared to hitting main memory. If your branch predictor can figure out the jmp over the int3 instructions quickly then that will also be fast. If the function is very short then the retguard stuff will add relatively more instructions to the function so will have a larger impact than if the function was long, etc. I found that the runtime overhead was about 2% on average, but there are many factors that contribute.
- Annatar 8y ago
  Yes. Any extra instructions will slow things down. The number of times the code runs will be the amplifying factor.

187 points by brynet 8y ago

trillic 8y ago

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

brynet 8y ago
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/libexec/ld.so/SPECS.randomdata https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib... [1] https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html
brandmeyer 8y ago
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).
- brynet 8y ago
  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.

brynet 8y ago

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=151123332419798&w=2 https://marc.info/?l=openbsd-cvs&m=152495643720502&w=2 https://marc.info/?l=openbsd-cvs&m=152495643720502&w=2

deleted 8y ago

[deleted]

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

deleted 8y ago

[deleted]

rurban 8y ago

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.

atonse 8y ago

While I didn't understand most of this, any reason why they're still using CVS? Genuinely curious, I'm sure they have good reasons.

davisr 8y ago
The developer makes the code, not the tools. Some people prefer tools different to others.
brynet 8y ago
You must be jealous that we're self-hosted. ;-)
- kazinator 8y ago
  I made a program called Meta-CVS in 2002 that stores a versioned directory structure with permissions and symbolic links along with the files in an ordinary CVS repository. http://www.kylheku.com/~kaz/mcvs.html http://www.kylheku.com/~kaz/mcvs.html Meta-CVS has an import feature (mcvs grab) which detects renamed files. It fixes up symlinks pointing to moved files too and such. Meta-CVS didn't catch on widely because by the time I had it stable, CVS itself was being side tracked by newly emerging projects like SVN. Plus people were afraid of it being written in Common Lisp. If you're still using CVS in 2018 and not Meta-CVS, you're ridiculously backwards though. :)
  - nickpsecurity 8y ago
    The need to secure repos was identified by Karger in MULTICS evaluation. It was a requirement in TCSEC security certification. A great summary of issues is below by David A. Wheeler: https://www.dwheeler.com/essays/scm-security.html https://www.dwheeler.com/essays/scm-security.html On top of yours, the OpenCM and Aegis programs attempted to meet some of these requirements. Most ignore them. Big, blind spot in software security.
busterarm 8y ago
They've managed to maintain a consistent roughly-6 month release cadence since 1995. CVS is working for them, so why switch?

amenghra 8y ago

The post from ~9 months ago by deraadt is worth reading: https://marc.info/?l=openbsd-tech&m=150317547021396&w=2 https://marc.info/?l=openbsd-tech&m=150317547021396&w=2

brynet 8y ago
That is the previous design which changed significantly from what's been committed today (see other comments). Github mirror, for easier review: https://github.com/openbsd/src/commit/e688c2b0648a80551cf7353d9f455c7cbb98f13c https://github.com/openbsd/src/commit/e688c2b0648a80551cf735...

kernoble 8y ago

What's meant by the term "gadget"? Does it mean an exploit mechanism? My searches are mostly showing information about USB device drivers.

deegles 8y ago
It's a reference to this class of vulnerabilities: https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming
- kernoble 8y ago
  Cool. Thanks!
tptacek 8y ago
In exploit development parlance, a gadget is a block of assembly instructions executed outside their intended order by an attacker-induced control transfer. A gadget might start in the middle of a basic block, for instance, and be invoked when an attacker uses a memory corruption vulnerability to overwrite a function pointer with an address they control. "Return oriented programming", which is kind of a dumb name, is the idea of harvesting gadgets from the text of a program and then using them as primitives for a new program. Gadgets are stitched together by the "return" instruction (hence the name ROP). When used by attackers this way, "ret" isn't really "returning" so much as it's being used as an arbitrary indirect jump mechanism.

mtgx 8y ago

Speaking of OpenBSD, does anyone know what happened here and how true it is? https://arstechnica.com/information-technology/2010/12/fbi-accused-of-planting-backdoor-in-openbsd-ipsec-stack/ https://arstechnica.com/information-technology/2010/12/fbi-a... It would certainly jive with John Gilmore's story on how the NSA worked through the standard bodies to keep IPSEC easily exploitable by making the design too difficult to implement properly: https://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html https://www.mail-archive.com/cryptography@metzdowd.com/msg12... Their behavior around Simon & Speck and how they refused to reveal details on how exploitable they could be also seems to be similar to their previous tactics. This is why it's worrisome that Google intends to implement Speck in Android and have pushed it to the Linux kernel, too. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da7a0ab5b4babbe5d7a46f852582be06a00a28f0 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... More details on how the NSA has been sabotaging open source projects here: https://www.youtube.com/watch?v=fwcl17Q0bpk https://www.youtube.com/watch?v=fwcl17Q0bpk

admax88q 8y ago
Don't have all my sources on hand, but the last time I looked in to this the general conclusion I came to was that there's evidence to suggest that someone was in fact paid to put vulnerabilities into the IPSec stack of OpenBSD. But there was no evidence to suggest that those vulnerabilities ever got written or if they were written that they ever made it into the source tree. I believe OpenBSD conducted an audit of their tree when rumours of an IPSec backdoor started and didn't find anything alarming.
- sverige 8y ago
  Pretty ancient stuff to bring up, especially in this context. Here's the last denial I recall by one of the people accused of planting backdoors in OpenBSD. Note the date. https://www.itworld.com/article/2744922/open-source-tools/openbsd-fbi-allegations-denied-by-named-participants.html https://www.itworld.com/article/2744922/open-source-tools/op...
  - 8y ago

nneonneo 8y ago

Cool. If I understand the LLVM code correctly, it's inserting the following instruction sequence into the code: mov r11, [cookie] xor r11, [rsp] ... xor r11, [rsp] cmp r11, [cookie] jeq 2 int 3 int 3 ret (where r11 might be some other suitable temp register as needed). cookie points to an 8-byte chunk of .openbsd.randomdata, a section that is initialized at binary load time by the kernel to contain random data. The canary is one of 4000 possible values, named "__retguard_0" through "__retguard_3999", presumably to avoid having the kernel generate an unbounded amount of random data - the section is limited to 1MB in size. This makes ret instructions fairly hard to use for rop purposes. Unlike the original design, which xor'd [rsp] directly, this new approach preserves return prediction so it should have a lesser effect on performance. With the changes to reduce polymorphic gadgets in place, this should make ROP attacks significantly less palatable. Also, in the original design, an arbitrary leak made rop attacks feasible as you could just place xor-encrypted return addresses on the stack. With the new design, you need repeatable register control too, assuming the temp register isn't spilled, which raises the bar quite a bit.

Annatar 8y ago
What is preventing an attacker from overwriting the last xor and cmp instruction sequence with nop instructions?
- ben_bai 8y ago
  W^X (W xor X) which means memory is either writeable or executable. Guess what, OpenBSD maps code only executable and not writeable.

Klasiaster 8y ago

The underlying assumption is that the XORd value cannot be crafted by the attacker. If read-access of [rsp] is possible, this scheme is vulnerable to information leak of the return address (or another program pointer which lets the attacker derive the return address), because cookie = retaddr^[rsp]. But still this is better than the original RETGUARD which was easier to attack in both ways, either a leak of the stack position to get the return address or vice versa.

tptacek 8y ago

I don't pay enough attention to know how this is different from what PaX team did with RAP 3 years ago: https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.p...

ectospheno 8y ago
They put it into a system people will actually use. Just leaving these here... https://www.theregister.co.uk/2017/06/26/linus_torvalds_slams_pure_garbage_from_clowns_at_grsecurity/ https://www.theregister.co.uk/2017/06/26/linus_torvalds_slam... https://www.theregister.co.uk/2018/01/19/grsecurity_libel_appeal/ https://www.theregister.co.uk/2018/01/19/grsecurity_libel_ap...
- tptacek 8y ago
  This is just drama and isn't informative in any way.
  - justinjlynn 8y ago
    It's informative in that it tells one that one should stay away from grsec's patch sets and why. When the BDFL of one's kernel says something like that, combined with how radioactive the community interaction seems to have been in the past, the notion that one might get sufficient support or have positive interactions with the wider community while using the grsec kernel fork is dubious at best.
    - tptacek 8y ago
      The idea that you should avoid grsecurity because Linus Torvalds, the "BDFL", says so is so messed up I actually don't know how to rebut it. Either way: I'm not saying Retguard is based on RAP --- my question was, "what's the relationship between the techniques". But if there is a relationship, OpenBSD should be explicit about it, so that we can keep track of the evolution of memory corruption countermeasures. I do not care whether you think people should or shouldn't run grsecurity.

DeepYogurt 8y ago

Question; does this protection get applied to all languages that use llvm on openbsd or is it C/C++ specific?

keyle 8y ago

When I first read this, I thought how come no one thought of this before? It feels like common sense. Dumb question (potentially): will this make code that is not inlined, calling a function many times, often, run a lot slower?

Mordak 8y ago
It depends on the function. Many things will contribute. If your CPU can keep the cookie in cache then loading it repeatedly will relatively fast compared to hitting main memory. If your branch predictor can figure out the jmp over the int3 instructions quickly then that will also be fast. If the function is very short then the retguard stuff will add relatively more instructions to the function so will have a larger impact than if the function was long, etc. I found that the runtime overhead was about 2% on average, but there are many factors that contribute.
Annatar 8y ago
Yes. Any extra instructions will slow things down. The number of times the code runs will be the amplifying factor.