Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSHD: Random boot time relinking, OpenBSD

undeadly.org

Post reply on HN
Print view View original

21–30 of 55 posts

Re: SSHD: Random boot time relinking, OpenBSD

#21

Post by nine_k »

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.

Re: SSHD: Random boot time relinking, OpenBSD

#22

Post by nine_k »

I remember how back in MS DOS days polymorphic viruses first appeared, in an attempt to avoid detection by antivirus software (useful and essential back then).

Now the tables have turned, and legitimate software has to become somehow polymorphic to thwart attacks by malware.

Re: SSHD: Random boot time relinking, OpenBSD

#23

Post by patrakov »

rollcat wrote: post #17
patrakov wrote: post #16

Earlier quoted context omitted.

Please don't throw out the baby with the bathwater. Fully reproducible builds provide great assurance against the supply chain attacks. But 100% reproducibility is in some cases a bit too much. What matters is whether the artifact can be easily proven to be functionally identical to the canonical one. So I am 100% for a fully predictable sshd random-relink kit, producing unpredictable sshd binaries, but only as long…

> So I am 100% for a fully predictable sshd random-relink kit, producing unpredictable sshd binaries, but only as long as there is an instruction how to check that the sshd binary that allegedly came from it indeed could have come from it, and was not quietly replaced by some malicious entity. You can easily verify the integrity of the object files that are used in the random relinking - they are included in the bina…

> You can easily verify the integrity of the object files that are used in the random relinking - they are included in the binary distribution, and are necessary to perform the relinking.

I don't understand the full logic here. Yes I can authenticate the object files. But how would you discern, after a possible intrusion, an "sshd" binary that is indeed a random combination of these objects, from a trojaned "sshd" binary?

Re: SSHD: Random boot time relinking, OpenBSD

#24

Post by codetrotter »

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.

I suppose if someone found a technique in the wild that defeats regular ASLR (even if only sometimes), they could then test that same technique against fine-grained ASLR and evaluate if the FG ASLR was more effective at preventing exploitation.

Re: SSHD: Random boot time relinking, OpenBSD

#25

Post by _0w8t »

patrakov wrote: post #23
rollcat wrote: post #17

Earlier quoted context omitted.

> So I am 100% for a fully predictable sshd random-relink kit, producing unpredictable sshd binaries, but only as long as there is an instruction how to check that the sshd binary that allegedly came from it indeed could have come from it, and was not quietly replaced by some malicious entity. You can easily verify the integrity of the object files that are used in the random relinking - they are included in the bina…

> You can easily verify the integrity of the object files that are used in the random relinking - they are included in the binary distribution, and are necessary to perform the relinking. I don't understand the full logic here. Yes I can authenticate the object files. But how would you discern, after a possible intrusion, an "sshd" binary that is indeed a random combination of these objects, from a trojaned "sshd" bi…

A local package manager that performs the linking can save the hash of the result.

Re: SSHD: Random boot time relinking, OpenBSD

#26

Post by wyldfire »

viraptor wrote: post #11
kryptiskt wrote: post #9

Earlier quoted context omitted.

Wouldn't the stack location be set at runtime and given by the stack register at the entry point?

I think I've got a better idea now. So openbsd has ASLR which affects data, code/library, and stack positions. Then this solution works on top of it by reordering symbols within the code. One thing I'm still not sure about is whether the kernel could theoretically do the same reordering at load time using relocatable symbols.

The assembler laid out the code within the sections and generally it's not changed after that (except for targets that do linker relaxation). However with -ffunction-sections the compiler would put each function in its own section which then can be independently relocated.

Re: SSHD: Random boot time relinking, OpenBSD

#27

Post by vlovich123 »

_0w8t wrote: post #25
patrakov wrote: post #23

Earlier quoted context omitted.

> You can easily verify the integrity of the object files that are used in the random relinking - they are included in the binary distribution, and are necessary to perform the relinking. I don't understand the full logic here. Yes I can authenticate the object files. But how would you discern, after a possible intrusion, an "sshd" binary that is indeed a random combination of these objects, from a trojaned "sshd" bi…

A local package manager that performs the linking can save the hash of the result.

And the exploited program acquired root and changes the hash?

Re: SSHD: Random boot time relinking, OpenBSD

#28

Post by rollcat »

vlovich123 wrote: post #27
_0w8t wrote: post #25

Earlier quoted context omitted.

A local package manager that performs the linking can save the hash of the result.

And the exploited program acquired root and changes the hash?

Limiting the scope of the damage that root can cause is an open problem, orthogonal to verifiable builds. OpenBSD has some basic checks in place (securelevel), but you should still assume that a compromised host is, well, compromised.

The weak link in reproducibility is that you currently have no trivial way of recreating the same random order of the linked object files.

Currently the random relinking is implemented literally through a call to "| sort -R" (-R for random order) on the list of object files, passed as arguments to the linker. I suppose if sort -R took a seed argument that was saved somewhere safe (chmod 400), the linking order can still be reproduced, and the resulting executable checksummed against the state of the system.

Re: SSHD: Random boot time relinking, OpenBSD

#30

Post by WhyNotHugo »

rwmj wrote: post #29

Takes some dedication to still be using CVS. Do they use another version control system to feed into CVS, or is CVS the tool they use directly?

They're working on GoT (game of trees), an OpenBSD-born client that interoperates with git repositories.

AFAIK, they still interface with CVS directly, but I assume the expectation is to eventually transition to got.

https://www.gameoftrees.org/

Post reply on HN