SSHD: Random boot time relinking, OpenBSD • Hacker News Board

Re: SSHD: Random boot time relinking, OpenBSD

#51

Post by codesniperjoe » Sat, Jan 21, 2023, 4:12 AM UTC

okl wrote: post #48

codesniperjoe wrote: post #33

Earlier quoted context omitted.

Yes, the base idea is not that new. I store since years every GO based application I use as small (few kb) source code tree checkout only, no binary at all. At runtime the wrapper compiles a randomized individual one-time-temporary-uniq binary via garble [0]. [0] https://github.com/burrowers/garble

How do you ensure that your compiler and libs are clean though?

The compiler (go) is part of a static read-only (compressed/in-memory) RootFS. Build on a air-gap build server, touching only signed/verified/reviewed code from git-offline mirror snaps. Go has no libs, all static. The resulting runtime only binaries are totally uniq/randomized and dependency free, straight from (signed) source code.

Re: SSHD: Random boot time relinking, OpenBSD

#52

Post by somat » Sat, Jan 21, 2023, 7:26 AM UTC

nine_k wrote: post #21

rfoo wrote: post #19

Does anyone know an actually-happened example case where a fine-grained ASLR (like the OpenBSD relink one) successfully mitigates or significantly hinders an exploit, and the usual ASLR doesn't? I'm curious because years ago the academic strongly pushes the FG ASLR story, then OpenBSD did kernel relinking, but I haven't heard any industry story on how effective this is.

How would you measure that? How would you notice a failed attempt at finding a hole, of stack smashing, etc, if it did not even result in a crash, or any other dysfunction? Not a rhetorical question.

My guess is you look for a security POC that reads something like "We were unable to build the ROP chain on openbsd due to the gadget locations being unknowable."

Re: SSHD: Random boot time relinking, OpenBSD

#53

Post by jcalvinowens » Sat, Jan 21, 2023, 5:07 PM UTC

rfoo wrote: post #19

Does anyone know an actually-happened example case where a fine-grained ASLR (like the OpenBSD relink one) successfully mitigates or significantly hinders an exploit, and the usual ASLR doesn't? I'm curious because years ago the academic strongly pushes the FG ASLR story, then OpenBSD did kernel relinking, but I haven't heard any industry story on how effective this is.

The traditional antidote to ASLR is "known code reuse", tricks like ret2libc, ret2plt, etc.

FG-ASLR helps because, even when you know where .text is, there are now N possible randomized locations for the piece of code your exploit leverages, so if you pick one and exploit M machines that way, only M/N of the exploits will succeed (where you got lucky).

Ultimately it is obfuscation, but with enough entropy it is very effective. It can't mitigate or prevent an exploit, but it makes it more work to turn an exploit into code execution consistently enough for it to be useful.

Re: SSHD: Random boot time relinking, OpenBSD

#54

Post by vlovich123 » Sun, Jan 22, 2023, 3:08 AM UTC

patrakov wrote: post #50

_0w8t wrote: post #46

Earlier quoted context omitted.

The hash can be uploaded somewhere. Alternatively a seed to randomize the executable can be derived from an immutable token like serial number. Yet another solution is to re-sort the executable into a stable order and compare the hash of that.

Actually, saving the hashes of the objects into the executable itself, into a new section, would be enough. Then one would need to locate this section, confirm that the hashes there form a permutation of the canonical ones, relink the canonical objects in the same order, and check whether the resulting executable is the same byte-for-byte.

If you save the link order, then you’ve provided a map to the stacker of the link order used which defeats the whole point of randomization. No? I must be missing something

Re: SSHD: Random boot time relinking, OpenBSD

#55

Post by patrakov » Sun, Jan 22, 2023, 8:10 AM UTC

vlovich123 wrote: post #54

patrakov wrote: post #50

Earlier quoted context omitted.

Actually, saving the hashes of the objects into the executable itself, into a new section, would be enough. Then one would need to locate this section, confirm that the hashes there form a permutation of the canonical ones, relink the canonical objects in the same order, and check whether the resulting executable is the same byte-for-byte.

If you save the link order, then you’ve provided a map to the stacker of the link order used which defeats the whole point of randomization. No? I must be missing something

The section with the link order stays only on disk, i.e. not loaded into RAM, and is therefore useless to the one who tries to exploit sshd. Especially because the sshd binary is readable only by root now.