[jacquesgt]

I feel like I’m missing something here. An infoleak is required to successfully ROP against ASLR (otherwise the attacker doesn’t know what to overwrite the return address with). Once an infoleak is available, the address of the stack can be leaked. I’m not really sure this does much beyond requiring attackers to modify their existing exploits.

[syncopate]

It increases the complexity of the attack. Usually, stack cookies make ROP harder these days but guessing the cookie only has a complexity of 8*256 (on OpenBSD), but xor'ing the return address with another value does increase the complexity even more. And that might be good news for programs that use fork a lot (like nginx) and hence don't get a refresh for ASLR/stack cookies for every request (like e.g. sshd on OpenBSD does [which does does fork/exec to ensure ASLR/cookies are refreshed]).

[brynet]

OpenBSD has been expanding the fork+exec model throughout its source tree, since the OpenSSH preauth work done by Damien Miller, many more followed. The list includes bgpd/ldpd/eigrpd/smtpd/relayd/ntpd/httpd/snmpd/ldapd and most recently slaacd & vmd.

A few remain but are being converted as they are discovered.

[hexadecimated]

Perhaps OpenBSD should consider randomizing the per-process stack canary value upon fork().

[syncopate]

How does that work? Should the kernel walk the stack to change all the saved cookie values of the forked copy? I doubt the kernel even knows where the saved cookie values are stored on the stack. Also, that would make fork quite slow, depending on how the deep the stack was when the fork happened.

[hexadecimated]

The post-fork canary value could be paired with the stack pointer at which it became valid. If not valid, the process could walk a linked list of pre-fork canary and stack pointer pairs, to find the correct value to use. Would be interesting to see the performance hit on such an approach.

[tedunangst]

Or not. The stack canary is not the only random value reset upon exec.

[brynet]

"ROP attack methods are impacted because existing gadgets are transformed to consist of '<gadget artifacts> <mangle ret address> RET'. That pivots the return sequence off the ROP chain in a highly unpredictable and inconvenient fashion."

[jacquesgt]

I'm not seeing how it's unpredictable and inconvenient. It's predictable if the stack address can be leaked (via a frame pointer leak, for example). It doesn't seem that inconvenient. Instead of including the address of a gadget in the chain, include the gadget xor the leaked stack address. What's the unpredictable and inconvenient part that I'm not seeing?

[Mordak]

You have it - if a stack address can be leaked, and you can follow the control flow to figure out the difference between the address you leaked and the address you're going to be dumping your ROP chain into, then you can just xor the gadget address with the stack address, and then do the math to xor any down-chain gadgets with the calculated stack address if the gadgets you want to use happen to have this xor instruction injected into them.

But you don't always have stack address leaks. Presently, in order to ROP you need (a) a leaked address to the space where your gadgets live and (b) the ability to write your ROP chain somewhere where the program will return into it. With this scheme, you now also need (c) the exact address where you are writing your ROP chain.

Not all info leak vulnerabilities leak arbitrary memory of the attacker's choosing. If they did, stack canaries would be pretty useless. So for those cases where a stack address leak is unavailable, this raises the bar against ROP.