undefined | Better HN

0 pointsvlovich1233y ago0 comments

And the exploited program acquired root and changes the hash?

0 comments

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.

_0w8t3y ago

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.

patrakov3y ago

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.

vlovich123OP3y ago

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

1 more reply

j / k navigate · click thread line to collapse