Live data from Hacker News

Retguard: An improved stack protector for OpenBSD

marc.info

71–73 of 73 posts

Re: Retguard: An improved stack protector for OpenBSD

#71
post #59
post #56

Earlier quoted context omitted.

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). I…

1. both insertReturnProtectorPrologue and insertReturnProtectorEpilogue check hasReturnProtectorTempRegister before proceeding with the instrumentation. so either the changes to calculateSaveRestoreBlocks are not enough to prevent that condition from ever triggering or these checks should be asserts at most or just be eliminated altogether.

2. sure but then this means that RETGUARD is not an improvement over Stackguard/SSP which is not how it's marketed...

3. shared means that entities of a class (threads in a process in userland, every single process/thread in the kernel) see the exact same cookies so leaking a cookie from one entity can allow exploitation by another. this is especially detrimental to the kernel side protection. frequent enough cookie rerandomization can help narrow this channel (RAP has a per-thread cookie in the kernel that is updated on each syscall, and there's some more to reduce infoleaks across kernel stacks, it's all in the presentation).

4. any normal path leading up to the ret is a gadget and int3 stuffing does nothing to prevent that (the underlying logic here is that if one can retarget a return to arbitary addresses then he has already leaked enough information so bypassing the cookie check is a no-brainer too). not only that but in the bsd.mp kernel i just checked, of the 32199 ret (0xc3) bytes only 20236 are actual retn insns, the rest are inside insns. so this int3 stuffing leaves many other instances available. Red Hat tried similar gadget elimination a while ago but noone's using the gcc feature as far as i can tell.

Re: Retguard: An improved stack protector for OpenBSD

#72
post #42

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.

It's a PITA for any reasonably large/old CVS repo. Partly because CVS is fundamentally broke.

Re: Retguard: An improved stack protector for OpenBSD

#73

Earlier quoted context omitted.

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!

Yes, it is the best OS for security, and the audits have gone on for the duration of the project.
Post reply on HN