Live data from Hacker News

Retguard: An improved stack protector for OpenBSD

marc.info

21–30 of 73 posts

Re: Retguard: An improved stack protector for OpenBSD

#23
post #21
post #11

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.

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.

Re: Retguard: An improved stack protector for OpenBSD

#24

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

It's a reference to this class of vulnerabilities: https://en.wikipedia.org/wiki/Return-oriented_programming

Re: Retguard: An improved stack protector for OpenBSD

#25
post #24

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

It's a reference to this class of vulnerabilities: https://en.wikipedia.org/wiki/Return-oriented_programming

Cool. Thanks!

Re: Retguard: An improved stack protector for OpenBSD

#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 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/lin...

More details on how the NSA has been sabotaging open source projects here:

https://www.youtube.com/watch?v=fwcl17Q0bpk

Re: Retguard: An improved stack protector for OpenBSD

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

Re: Retguard: An improved stack protector for OpenBSD

#28
post #23
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.

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

Re: Retguard: An improved stack protector for OpenBSD

#29
post #20
post #19

Earlier quoted context omitted.

I actually wasn't clear at all. To me, it's more about code browseability, and I've found it much easier to splunk through codebases for fun in a GitHub-like interface. (Not much to do with the developers' workflows, I suppose) That's really where it's coming from, wasn't really trying to be snarky or anything.

If nothing else, nobody "owns" CVS. Github (and thus, effectively git by sheer mass) is now owned by Microsoft.

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.

Re: Retguard: An improved stack protector for OpenBSD

#30
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.
Post reply on HN