Retguard: An improved stack protector for OpenBSD • Hacker News Board

Re: Retguard: An improved stack protector for OpenBSD

#51

Post by staticassertion » Wed, Jun 06, 2018, 9:41 PM UTC

justinjlynn wrote: post #48

tptacek wrote: post #37

Earlier quoted context omitted.

This is just drama and isn't informative in any way.

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.

Oh, please. If you want to throw stones about behavior in the Linux kernel you're going to need to throw them at a hell of a lot more people than Grsec - there's decades of shit piled up.

Linus has always been a total blowhard when it comes to... everything, but in particular when it comes to security. I wouldn't take his opinions too seriously on the matter.

The fact is that grsec still maintains the state of the art for memory safety mitigations.

Re: Retguard: An improved stack protector for OpenBSD

#52

Post by justinjlynn » Wed, Jun 06, 2018, 10:06 PM UTC

tptacek wrote: post #50

justinjlynn wrote: post #48

Earlier quoted context omitted.

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.

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 n…

I don't avoid grsec because Linus says so. I avoid it because he says they break things when they don't need to. Security is a trade-off and I trust Linus in judging that and in ensuring the operating system should never break user space, unless it absolutely has to. If it does, I sure don't want to be stuck going to a group that goes against the spirit of the GPL (by punishing users who redistribute by cutting them off from future access) and which sues prominent members of the community essentially for pointing this out; which pretty much ensures I will be stuck going to them for support and not redistributing their work as I am permitted to under the GPL. No thanks to that kind of coercion!

I too am curious what the technical basis is for the patch but your assertion that drama is irrelevant is dangerous when applied to community projects that exist because of the goodwill of their members. grsec should be called out, when mentioned, because of their demonstrated ability to make the code they do produce less than useful because of the encumbrance it carries due to its origin.

Re: Retguard: An improved stack protector for OpenBSD

#53

Post by justinjlynn » Wed, Jun 06, 2018, 10:10 PM UTC

staticassertion wrote: post #51

justinjlynn wrote: post #48

Earlier quoted context omitted.

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.

Oh, please. If you want to throw stones about behavior in the Linux kernel you're going to need to throw them at a hell of a lot more people than Grsec - there's decades of shit piled up. Linus has always been a total blowhard when it comes to... everything, but in particular when it comes to security. I wouldn't take his opinions too seriously on the matter. The fact is that grsec still maintains the state of the ar…

grsec may maintain state of the art, but it doesn't matter if one can't use their code because of the potential for breakage and toxic licensing conditions under which one would have to use it should one choose to do so. I also would not want to support a group which,according to the OSI, violates the spirit of the licence upon which their state of the art work is based - and which certainly violates generally accepted community norms.

Re: Retguard: An improved stack protector for OpenBSD

#54

Post by tptacek » Wed, Jun 06, 2018, 10:47 PM UTC

justinjlynn wrote: post #52

tptacek wrote: post #50

Earlier quoted context omitted.

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 n…

I don't avoid grsec because Linus says so. I avoid it because he says they break things when they don't need to. Security is a trade-off and I trust Linus in judging that and in ensuring the operating system should never break user space, unless it absolutely has to. If it does, I sure don't want to be stuck going to a group that goes against the spirit of the GPL (by punishing users who redistribute by cutting them…

None of this has anything to do with my question and I'll ask that you not use my comments as a coat rack to hang your unrelated concerns about grsecurity off of.

I'm asking a research question, not a user question.

Thanks.

Re: Retguard: An improved stack protector for OpenBSD

#55

Post by justinjlynn » Wed, Jun 06, 2018, 11:22 PM UTC

tptacek wrote: post #54

justinjlynn wrote: post #52

Earlier quoted context omitted.

I don't avoid grsec because Linus says so. I avoid it because he says they break things when they don't need to. Security is a trade-off and I trust Linus in judging that and in ensuring the operating system should never break user space, unless it absolutely has to. If it does, I sure don't want to be stuck going to a group that goes against the spirit of the GPL (by punishing users who redistribute by cutting them…

None of this has anything to do with my question and I'll ask that you not use my comments as a coat rack to hang your unrelated concerns about grsecurity off of. I'm asking a research question, not a user question. Thanks.

I was responding to your comment that the concerns raised by GP were drama and irrelevant. They are relevant to this subthread. I've said what I wish to say on the matter as well.

Re: Retguard: An improved stack protector for OpenBSD

#56

Post by PaXTeam » Wed, Jun 06, 2018, 11:55 PM UTC

tptacek wrote: post #34

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.p...

this is basically the xor canary approach originally pioneered by the Stackguard guys (i'm pretty sure you were already around at the time though probably forgot such old history as did the rest of the world apparently ;). the OpenBSD implementation suffers from a few problems, mostly their own making:

1. if they can't find a register to load the cookie into, they'll silently skip instrumentation (i'm not sure how that would happen in practice but the silent treatment when omitting a security feature is a non-starter).

2. if they can find such a register then it'll be spilled to the stack and restored in the epilogue, so a normal buffer overflow can control both the xor'd retaddr and the retaddr itself and the only thing standing in the way of exploitation is the secret cookie value - not unlike with Stackguard/SSP.

3. one would think that a per-function cookie is an improvement but... they're shared among threads (in userland) or everything (in the kernel) so infoleaks are just as catastrophic as before (it'd certainly help if someone described a proper threat model for this defense). at least the kernel side should use a per-syscall cookie to make it somewhat resemble an actual defense mechanism (and there's some more described in my presentation).

4. the int3 stuffing before retn must be someone's joke 'cos it sure as hell won't prevent abusing the retn as a gadget. it does introduce a mispredicted branch for every single function return however.

Re: Retguard: An improved stack protector for OpenBSD

#57

Post by sverige » Wed, Jun 06, 2018, 11:56 PM UTC

admax88q wrote: post #36

mtgx wrote: post #26

Speaking of OpenBSD, does anyone know what happened here and how true it is? 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/msg12... Their behavior around Si…

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 t…

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/op...

Re: Retguard: An improved stack protector for OpenBSD

#58

Post by justinjlynn » Thu, Jun 07, 2018, 12:19 AM UTC

PaXTeam wrote: post #56

tptacek wrote: post #34

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.p...

this is basically the xor canary approach originally pioneered by the Stackguard guys (i'm pretty sure you were already around at the time though probably forgot such old history as did the rest of the world apparently ;). the OpenBSD implementation suffers from a few problems, mostly their own making: 1. if they can't find a register to load the cookie into, they'll silently skip instrumentation (i'm not sure how th…

Thanks for the summary, comparison and criticism. Cheers

Re: Retguard: An improved stack protector for OpenBSD

#59

Post by Mordak » Thu, Jun 07, 2018, 1:08 AM UTC

PaXTeam wrote: post #56

tptacek wrote: post #34

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.p...

this is basically the xor canary approach originally pioneered by the Stackguard guys (i'm pretty sure you were already around at the time though probably forgot such old history as did the rest of the world apparently ;). the OpenBSD implementation suffers from a few problems, mostly their own making: 1. if they can't find a register to load the cookie into, they'll silently skip instrumentation (i'm not sure how th…

Hey PaXTeam, thanks for having a look! I wrote the implementation, so I can answer some of these.

1. We don't silently skip instrumentation. If we can't find a free register then we will force the frame setup code to the front of the function so we can get one. See the diff in PEI::calculateSaveRestoreBlocks().

2. We do spill the calculated value to the stack. This is unavoidable in many cases (non-leaf functions). It would be an optimization to not do this in leaf functions, but this would also mean finding a register that is unused throughout the function. This turns out to be a small number of functions, so we didn't pursue it for the initial implementation.

3. I'm not sure what you mean by the cookies are shared. Do you just mean that they are all in the openbsd.randomdata section? They have to live somewhere. Being able to read arbitrary memory in the openbsd.randomdata section would leak them, yes, though this doesn't seem to have been a problem for the existing stack canary, which lives in the same section. I see that RAP keeps the cookie on a register, which sounds like a neat idea. I'd be curious to see how you manage to rotate the cookie arbitrarily.

4. I'm glad you like the int3 stuffing. :-) We could always make the int3 sled longer if it turns out these rets are still accessible in gadgets that terminate on the return instruction. Have you found any?

Anyway, I'm happy to see your commentary on this. You guys do some nice work! If you have other suggestions for improvement I'd be happy to hear them. You can email me at mortimer@.

Re: Retguard: An improved stack protector for OpenBSD

#60

Post by foodstances » Thu, Jun 07, 2018, 1:10 AM UTC

hoistbypetard wrote: post #47

ksec wrote: post #23

Earlier quoted context omitted.

That was my first thought as well, then I realise CVS is not maintained for more then a decade. I know not everyone likes Git but wouldn't SVN be a better solution.

The OpenBSD project maintains its own fork: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cvs/ It's not especially active, but you can see the last change sets were in the past year, so "not maintained for more than a decade" doesn't apply to what they're using.

That is not a fork, that is OpenCVS which is a brand new, from-scratch implementation. It's not yet being used to host the OpenBSD code (but some AnonCVS mirrors use it).

The CVS that OpenBSD uses is still GNU CVS - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/cv...