Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Retguard: An improved stack protector for OpenBSD

marc.info

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Retguard: An improved stack protector for OpenBSD

#61

Post by gmfawcett »

sthen wrote: post #42
gmfawcett wrote: post #29

Earlier quoted context omitted.

Your "MS owns Git" argument is silly. By analogy, Facebook and Reddit must own HTML, because they are such popular Web sites. OpenBSD could easily use Git if they wanted to, and they'd never have to touch MS code, or an MS Web property.

If you can say "easily" for this, you can't have tried actually importing the OpenBSD CVS repository into git. cvs2gitdump doesn't do too bad of a job, but doesn't attempt tags and branches. I haven't found another conversion tool that gets anywhere close.

I'm not suggesting that CVS to Git is easy. I'm just saying that Github doesn't present any kind of barrier to adoption of Git (in any project, not just OpenBSD).

Re: Retguard: An improved stack protector for OpenBSD

#63

Post by [deleted] »

toast0 wrote: post #28
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.

> CVS is not maintained for more then a decade Have you considered CVS may have been finished for over a decade? OpenBSD has been using it for a long time, and it clearly meets their needs, or they'd chose from one of the many other choices. In my own experience, it's nice to use finished software, step off of the upgrade treadmill, and get to the end of the learning curve.

[deleted]

Re: Retguard: An improved stack protector for OpenBSD

#64

Post by Mordak »

keyle wrote: post #62

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?

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.

Re: Retguard: An improved stack protector for OpenBSD

#65

Post by hoistbypetard »

foodstances wrote: post #60
hoistbypetard wrote: post #47

Earlier quoted context omitted.

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

Looking at my local system, you're exactly right. /usr/bin/cvs is still GNU CVS, and you have to explicitly use /usr/bin/opencvs to get this.

I thought I remembered -current moving to opencvs some time ago, but either I mis-remembered or they moved back.

Re: Retguard: An improved stack protector for OpenBSD

#66

Post by reacharavindh »

sverige wrote: post #57
admax88q wrote: post #36

Earlier quoted context omitted.

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

Sorry to indulge in tin foil hattery. But this all seems in conclusive.. has there been an independent audit of the components involved?

Re: Retguard: An improved stack protector for OpenBSD

#67

Post by reacharavindh »

reacharavindh wrote: post #66
sverige wrote: post #57

Earlier quoted context omitted.

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

Sorry to indulge in tin foil hattery. But this all seems in conclusive.. has there been an independent audit of the components involved?

Following up my own question. Just read the security and audit details on OpenBSD page.

https://www.openbsd.org/security.html

It appears that there is a continuous audit of source code. So, even if a malicious hole was planted, it ought to be discovered in the years of repeated auditing. Cheers to OpenBSD!

Re: Retguard: An improved stack protector for OpenBSD

#68

Post by Annatar »

nneonneo wrote: post #27

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

What is preventing an attacker from overwriting the last xor and cmp instruction sequence with nop instructions?

Re: Retguard: An improved stack protector for OpenBSD

#69

Post by Annatar »

keyle wrote: post #62

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?

Yes. Any extra instructions will slow things down. The number of times the code runs will be the amplifying factor.

Re: Retguard: An improved stack protector for OpenBSD

#70

Post by ben_bai »

Annatar wrote: post #68
nneonneo wrote: post #27

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

What is preventing an attacker from overwriting the last xor and cmp instruction sequence with nop instructions?

W^X (W xor X) which means memory is either writeable or executable. Guess what, OpenBSD maps code only executable and not writeable.
Post reply on HN