I remember how back in MS DOS days polymorphic viruses first appeared, in an attempt to avoid detection by antivirus software (useful and essential back then).<p>Now the tables have turned, and legitimate software has to become somehow polymorphic to thwart attacks by malware.
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?<p>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.
In order to enable relinking, they had to keep around all original .o and .a files, as well as a Makefile. Not a problem for OpenBSD but pretty unusual for binary Linux distros.<p>I wonder if it is possible to make a relinker which only requires binary output -- so it could be easily incorporated into existing systems.<p>One way I can think of is to keep relocation/original object information in the debug sections, so that one can reconstruct original object files and re-link them. But I am guessing this will not work with LTO though... Or maybe we can just make a bunch of debug sections and store input object/library files verbatim -- this will at least double the binary size, but will allow for easier relinking.
Finally!<p>At least, someone finally understands that static, fully predictable, reproduce-able-builds are only an convenience feature for the attacker side.
What impact will this have on anti-tampering software that looks for changes in executable checksums? Tripwire and OSSEC come to mind and both can report their findings to a centralized server. Do package manager integrity tests still work? I assume anyone here using BSD in a PCI environment have already figured something out. Some people also feed checksums into Splunk.
Dynamic re-linking is cool, but it can result in less-than-optimal executables.<p>Sometimes it can be beneficial to optimize the link so most of the main thread stays in cache. Obviously this only really matters for CPU-intensive programs.
If a squint hard then this is a custom dynamic loader for .o files with rudimentary ASLR (where all your entropy comes from the permutation of the .o files), that happens to cache to disk.