[patrakov]

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

[_0w8t]

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

[vlovich123]

And the exploited program acquired root and changes the hash?

[rollcat]

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.

[_0w8t]

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.

[patrakov]

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.

[vlovich123]

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

[patrakov]

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.