Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
1–10 of 84 posts
Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
#2> 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.
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?
Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
#3>> As a side-effect, reproducible builds, which this technique breaks, are less of a concern anyway (because you've compiled your system from source).
Reproducible builds verify the source code and build process (including options) were the same. Not sure how important each aspect is.
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.
Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
#4>> As a side-effect, reproducible builds, which this technique breaks, are less of a concern anyway (because you've compiled your system from source). Reproducible builds verify the source code and build process (including options) were the same. Not sure how important each aspect is. 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…
Why? If the dependencies are dynamically loaded libraries it shouldn't matter?
Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
#5I 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.
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.
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.
Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
#6I 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 ha…
[deleted]
Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
#7Openbsd also puts a fair amount of work into removing ROP gadgets.
For example.
Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
#8I like this idea. I have an idea for something that would be cool, if impractical: Imagine a GCC wrapper that doesn't actually link, but produces a bundle that performs the linking in randomized order in realtime and then runs.
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.
Side-effect: Does not work for libraries without a significantly more complex wrapper that certainly could not work for all libraries. Though, you could re-order the objects within a static library fairly easily.
Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
#9>> As a side-effect, reproducible builds, which this technique breaks, are less of a concern anyway (because you've compiled your system from source). Reproducible builds verify the source code and build process (including options) were the same. Not sure how important each aspect is. 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…
Control over the RNG seed, and tracking that seed as an 'input', would be a way to get reproducible builds while still having randomization.
Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?
#10>> As a side-effect, reproducible builds, which this technique breaks, are less of a concern anyway (because you've compiled your system from source). Reproducible builds verify the source code and build process (including options) were the same. Not sure how important each aspect is. 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…
Isn’t it impossible to have truly from-scratch reproducible builds? IIRC, you have to trust the compiler which can’t be built from scratch.