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

31–40 of 73 posts

Re: Retguard: An improved stack protector for OpenBSD

#31

Post by atonse »

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.

Are you suggesting that there is nothing about CVS that frustrates its users? Surely there is always room for improvement, even if for performance reasons.

Feature bloat, totally agree. But even for bug fixes and performance improvements, I have a hard time believing this is truly finished.

Re: Retguard: An improved stack protector for OpenBSD

#32

Post by krylon »

ksec wrote: post #23
w8rbt wrote: post #21

Earlier quoted context omitted.

It is simple, they know it well and it works. Just like C89.

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.

I vaguely remember the OpenBSD people started a rewrite of CVS at one point. I am not sure where that went, but looking at other things they have rewritten (NTP, SMTP, HTTP, ...), I would be surprised if that did not work out.

Re: Retguard: An improved stack protector for OpenBSD

#33

Post by tptacek »

kernoble wrote: post #22

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

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.

Re: Retguard: An improved stack protector for OpenBSD

#35

Post by ectospheno »

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

They put it into a system people will actually use.

Just leaving these here...

https://www.theregister.co.uk/2017/06/26/linus_torvalds_slam...

https://www.theregister.co.uk/2018/01/19/grsecurity_libel_ap...

Re: Retguard: An improved stack protector for OpenBSD

#36

Post by admax88q »

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 their tree when rumours of an IPSec backdoor started and didn't find anything alarming.

Re: Retguard: An improved stack protector for OpenBSD

#37

Post by tptacek »

ectospheno wrote: post #35
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...

They put it into a system people will actually use. Just leaving these here... https://www.theregister.co.uk/2017/06/26/linus_torvalds_slam... https://www.theregister.co.uk/2018/01/19/grsecurity_libel_ap...

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

Re: Retguard: An improved stack protector for OpenBSD

#38

Post by toast0 »

atonse wrote: post #31
toast0 wrote: post #28

Earlier quoted context omitted.

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

Are you suggesting that there is nothing about CVS that frustrates its users? Surely there is always room for improvement, even if for performance reasons. Feature bloat, totally agree. But even for bug fixes and performance improvements, I have a hard time believing this is truly finished.

I suspect that any remaining user frustrations are either issues with fundamentals of the design, impossible to fix without frustrating other users, or don't rise up to the level of a bug report, let alone a patch.

Based on the timeline of CVS, I doubt there are that many large performance issues that can be fixed without significant risk of breaking. In my experience, CVS was primarily limited by network and disk I/O, both if which ate generally much improved since the time of active CVS development.

Keep in mind that the effective scope of CVS is also shrinking as many users move on to other software; that means any issues are less likely to surface.

Re: Retguard: An improved stack protector for OpenBSD

#39

Post by foodstances »

krylon wrote: post #32
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.

I vaguely remember the OpenBSD people started a rewrite of CVS at one point. I am not sure where that went, but looking at other things they have rewritten (NTP, SMTP, HTTP, ...), I would be surprised if that did not work out.

https://www.openbsd.org/opencvs/index.html

Re: Retguard: An improved stack protector for OpenBSD

#40

Post by forapurpose »

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…

The issue has been discussed many times on HN. My guess is that people don't want to revisit it (and I don't know enough off the top of my head to write a good answer). Look at HN history and you can find much of what you need.
Post reply on HN