I like this idea. I have an idea for something that would be cool, if impractical: Imagine a GCC wrapper that <i>doesn't</i> actually link, but produces a bundle that performs the linking in randomized order in realtime and then runs.<p>I think that you could do this quite well on NixOS, and I'm now intrigued to try to rig up a proof-of-concept when I can find the time.<p>Side-effect: Does not work for libraries without a significantly more complex wrapper that certainly could not work for all libraries. Though, you <i>could</i> re-order the objects within a static library fairly easily.
I wonder if just shuffling it on every release (even minor) isn’t sufficient (and actually even publishing that order). That doesn’t have full security benefit (attackers have a finite set of options) but keeps reproducible builds and the ability to distribute pre-linked binaries while raising the attack complexity significantly since no two machines are likely running the exact same version. That means an exploit has to try several different versions. Taking this a step further, create link N randomly sorted copies per version and randomly distribute those. Now the space to search through is large and the probability of picking the correct gadget variant goes down with 1/MN where there are M releases being attacked and N variants per release that might be installed (a targeted attack or an attack of a specific version only gets 1/N). Additionally, deterministic builds maintain your ability to audit binaries and their providence fairly easily (only grows linearly) while the risk of noticing the attempt without a successful exploit is N-1/N.<p>I’m not saying it’s perfect but it seems like a reasonable defense for binary distribution. As someone who used to run Gentoo, I’d say most people are in favor of the faster times to install a new package.<p>EDIT: extending this idea further, I wonder if compilers can’t offer a random seed to supply that causes a random layout of the sections within a built execution so that even statically linked binaries benefit from this.
Openbsd also puts a fair amount of work into removing ROP gadgets.<p>For example.<p><a href="https://marc.info/?l=openbsd-cvs&m=152824407931917" rel="nofollow">https://marc.info/?l=openbsd-cvs&m=152824407931917</a>
Lack of reproducible builds seems like a big cost here.<p>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.<p>Just-in-time gets you reproducible builds, and also addresses the "local attackers who can read the binary or library" problem.<p>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.<p>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.<p>Another advantage is that this approach should be feasible on an OS like Ubuntu where everything is precompiled.<p>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.<p>Performance-sensitive users could be given a way to turn the feature off, in cases where fast startup time was more important than security.
>> As a side-effect, reproducible builds, which this technique breaks, are less of a concern anyway (because you've compiled your system from source).<p>Reproducible builds verify the source code and build process (including options) were the same. Not sure how important each aspect is.<p>Also, if for some reason you rebuild a dependency, you'll need to relink everything that depends on that. This could get messy, but it's still interesting.
I'm guessing "dev-libs/openssl shuffleld" should go into "/etc/portage/package.env" instead (in the appendix).
> <i>The potential issue comes from the assumption that all .o files will be given continuously in the command line. The assumption appear to hold, but could blow up down the road. But well, it's hack.</i><p>Other than this issue (which may well be a large / unsolvable one), I wonder what other disadvantages to this approach there might be. Does this hack have any potential for a Gentoo profile or mainlining?
Don't try this with C++, unless you're certain that there are no interdependencies or side-effects in global variable initialisation. The link order (usually) affects the order in which initialisers are executed.
How does this work with dynamic libraries (shared objects). In Windows land, you get a .lib with a .dll and afaik that has hardcoded function addresses. You statically link the "import library" .lib with your exe, so if you randomize the function addresses and rebuild just the .dll later, it blows up (you need to rebuild all exes as well).<p>Is dynamic linking in Unix world truly runtime-only (a-la "GetLibrary" / "GetProcAddress")?
One gap to this approach: gcc can use argument files (pass a file that contains the actual arguments). I've only really seen this with build systems that expect to work on large numbers of arguments that will not fit on the command line. Still, something to be aware of.