| Lack of reproducible builds seems like a big cost here. I wonder if there's a way to do just-in-time random relinking such that the performance cost is low, but the security benefit is still strong. Just-in-time gets you reproducible builds, and also addresses the "local attackers who can read the binary or library" problem. There would be a performance cost in terms of startup time, but since the number of possible permutations is a factorial function of the number of possible linking orders, it seems like even a very coarse-grained random relinking can go a long way. You could accomplish this by doing static analysis of a binary to generate a file full of hints for ways to rewrite the binary such that its behavior is provably equivalent to the original. Then there could be a wrapper (perhaps at the shell or OS level) which uses the hints to randomly relink on the fly just prior to execution. Another advantage is that this approach should be feasible on an OS like Ubuntu where everything is precompiled. However the static analysis part could be a little tricky? I'm not familiar with the state of the art in static analysis of compiled binaries. Performance-sensitive users could be given a way to turn the feature off, in cases where fast startup time was more important than security. |
The biggest benefit seems to be in making it infeasible/dangerous for a malicious actor to distribute binary versions containing different behavior from the published source.
On a local machine, when and with what would you compare your binaries?