Hacker News Reader

Comment by mrb | Hacker News Reader

"To deter code reuse exploits, rc(8) re-links libc.so on startup, placing the objects in a random order."

I love this defense in depth, buried in the release notes... https://www.openbsd.org/60.html

This is pretty much useless. Attackers have moved on to using information leaks in order to determine memory layout and placement of objects.

So in practice, this doesn't really deter anything. Information leaks are everywhere.

I don't know why you're being down voted. We've had ASLR in Linux for years and various attacks have been successful.

The string format attack is the one I remember most clearly which basically renders ASLR useless.

Obviously it's not useless. Not all attackers have agreed collectively to use differents methods. Also, if it leaks in multiple points, it's better to start from a hole instead of letting it all go before finding a patch big enough for all.

Pretty much any security measure in isolation can be bypassed. So you need to stack as many as are reasonable on top of each other to limit the attacker's toolkit.

This change is basically free and makes certain things more difficult for attackers, so why not?

Attacker-controlled format strings are very convenient bugs, but they can't do everything. Consider the program:

    int main() {
        char buf[20];
        fgets(buf, sizeof buf, stdin);
        printf(buf);
        return 0;
    }

An attacker writing to the program's stdin can read at offsets to the stack (e.g. "%42$x"), read the contents of arbitrary non-null memory (e.g. "ABCD%5$s", where ABCD is a 32-bit memory address, and 5 is the positional parameter corresponding to the start of buf), and write an arbitrary value to an arbitrary address (e.g. "ABCD%38x%5$n", to write the value 42 to address 0x44434241).

A significant limitation of the vulnerability in the above program is the attacker can't, in a single execution of the program, read a value, then do computations on it locally, then write a value based on those computations. This flexibility is needed in order to bypass ASLR.

Kudos for the worked example!

Without this patch, using an information leak to bypass ASLR would be as simple as leaking any address in libc (__libc_start_main is often convenient since it's where main returns to when the progam ends, and hence is already on the stack), subtracting the (fixed, public) offset from the leak to calculate the base address libc was loaded at, and adding the (again fixed and public) offset from libc's base to some useful function (e.g. system(3)).

With this patch, the order of symbols are randomized every boot, so the offsets that were previously fixed and public aren't.

It's probably still possible, if you have multiple adaptive memory reads, to traverse the datastructures that legitimate programs use to find the order of the symbols, but a) not all information leaks can be used to read arbitrary addresses multiple times, and b) the traversal code becomes more complicated for the attacker to {write,maintain} relative to the simple arithmetic that was previously possible.

The above analysis is for remote exploits, local privilege escalation exploits can just read libc to determine the order (since it's re-linked on boot, not per process).

Reply on news.ycombinator.com