[saagarjha]

One might wonder how high this raises the bar; that is, what how an attacker would generally respond to full RELRO. The answer is usually that one would go after other data pointers not secured by RELRO. If there’s any in the binary, that’s the best, but otherwise usually you leak information about libc and target something like the malloc or free hooks which are likely to be called.

[nvarsj]

It definitely makes generic exploits harder. Without RELRO it's easy to leak libc once you find an overflow. You can also easily take control via overwriting the GOT pointers. Unsure what you mean by any in the binary - with PIE you can't do much even if you know a fixed offset, unless you can leak the binary location. Although if you can read/write into the stack you can usually find something useful regardless of RELRO/etc.

One of my favorite examples of bypassing relro is the sudo exploit that took advantage of a simple format string vulnerability. It was downplayed at the time by the sudo maintainer as not easy to exploit due to FORTIFY. But you could get full root just doing a very simple payload, because sudo already calls system(/bin/sh) and FORTIFY itself was easily exploitable. [1][2]

1: https://www.sudo.ws/alerts/sudo_debug.html

2: https://www.vnsecurity.net/research/2012/02/16/exploiting-su...

[saagarjha]

If you can write to the GOT, you can also likely write to function pointers in the binary's data segment. (Which is generally harder to set up, which is why RELRO is useful.)