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

11–20 of 55 posts

Re: SSHD: Random boot time relinking, OpenBSD

#11

Post by viraptor »

kryptiskt wrote: post #9
viraptor wrote: post #8

Earlier quoted context omitted.

Ah, so that will have some features of ASLR missing. Specifically, you can't do this on a read only root and it didn't randomise the stack location as far as I can tell?

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.

Re: SSHD: Random boot time relinking, OpenBSD

#12

Post by actionfromafar »

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.

Sounds like Amiga HUNK format with the HUNK_OVERLAY hunk. For instance various functions could be loaded anywhere in memory.

Re: SSHD: Random boot time relinking, OpenBSD

#15

Post by saagarjha »

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 kernel needs a bit more information than that, since chunks of code can refer to each other and if you rearrange them this would break these since they're typically emitted as relative offsets.

Re: SSHD: Random boot time relinking, OpenBSD

#16

Post by patrakov »

codesniperjoe wrote: post #2

Finally! At least, someone finally understands that static, fully predictable, reproduce-able-builds are only an convenience feature for the attacker side.

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 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.

Re: SSHD: Random boot time relinking, OpenBSD

#17

Post by rollcat »

patrakov wrote: post #16
codesniperjoe wrote: post #2

Finally! At least, someone finally understands that static, fully predictable, reproduce-able-builds are only an convenience feature for the attacker side.

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 binary distribution, and are necessary to perform the relinking.

The debate of static vs dynamic linking is still going on, and a very strong argument against static linking has always been that upgrading vulnerable libraries is made difficult. But think of it: package managers already hold the meta-data of what links to what; object files can be distributed just as easily as shared objects; the last necessary step is to move the actual linking step from the kernel to the package manager.

Re: SSHD: Random boot time relinking, OpenBSD

#18

Post by camgunz »

somat wrote: post #7
camgunz wrote: post #5

Earlier quoted context omitted.

Yeah I was just thinking this; I've got like years of uptime on my OpenBSD server--don't know how much boot time relinking is helping me. But for like, desktops and laptops, it's fine and a great feature IMO (you probably wade through a lot more muck on a personal machine)

If you have years of uptime on an openbsd machine you are not keeping it up to date. I have to admit I am guilty of this as well, but any mantained openbsd setup should have an uptime of no more than 6 months and a well maintained openbsd setup will be shorter than that as security patches are applied. Having said that one of the things I like about openbsd is that if you want to go dark and have an ultra stable syst…

This is true; my VPS has some kind of problem updating a FDE machine and I've procrastinated doing something about it for years. The answer is probably putting everything on tarsnap and reinstalling.

Re: SSHD: Random boot time relinking, OpenBSD

#19

Post by rfoo »

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.

Re: SSHD: Random boot time relinking, OpenBSD

#20

Post by wahern »

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…

On OpenBSD all static system binaries are compiled as static PIE, so they already benefit from ASLR. The issue, IIUC, is that ASLR only randomizes entire ELF sections relative to each other. In any executable or library, whether static or dynamic, the code is placed into one giant .text section, so the relative offsets remain static. In a dynamic executable all library dependencies are loaded separately, so at least each section of each library gets a unique base address. A leak that exposes the address of a function only leaks the address of other functions in that library, not every function in the process. But in a static executable all those libraries are also placed into the same .text section as the main program code, so a leak of any function address leaks all function addresses.

In theory all functions, or more realistically groups of functions spanning page-size increments, could be dynamically located. The obvious way to achieve that would be to have multiple .text sections within a main executable or library. But off-hand I don't know if that's actually supported by ELF, or if so whether the standard tool chains and environments could easily support it.

Post reply on HN