Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

quitesimple.org

Post reply on HN
Print view View original

21–30 of 84 posts

Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

#21

Post by Karellen »

kwhitefoot wrote: post #18

ROP gadgets?

https://en.wikipedia.org/wiki/Return-oriented_programming

> Return-oriented programming (ROP) is a computer security exploit technique that allows an attacker to execute code in the presence of security defenses[1][2] such as executable space protection and code signing.[3]

> In this technique, an attacker gains control of the call stack to hijack program control flow and then executes carefully chosen machine instruction sequences that are already present in the machine's memory, called "gadgets".[4][nb 1] Each gadget typically ends in a return instruction and is located in a subroutine within the existing program and/or shared library code.[nb 1] Chained together, these gadgets allow an attacker to perform arbitrary operations on a machine employing defenses that thwart simpler attacks.

Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

#22

Post by notpushkin »

vlovich123 wrote: post #5

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 ha…

For binary distributions, how about shipping object files and linking them on install with mold? This should be faster than compiling from source, just marginally slower than installing pre-linked binaries, and each build will be as unique as it gets.

Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

#23

Post by blibble »

jchw wrote: post #15
xxpor wrote: post #14

Earlier quoted context omitted.

That'd make process startup EXTREMELY slow

It's pretty much what OpenBSD is doing at bootup. Truthfully though you're right, using typical linkers, this would be pretty slow; at least a few seconds for large binaries, to minutes for things as large as web browsers. However, for many binaries, linking can be done much faster; mold claims to be only 50% the runtime of using `cp` on the object files, which is fast enough to even re-link Firefox on-the-fly withou…

I thought openbsd did it after boot?

Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

#25

Post by londons_explore »

matzf wrote: post #17

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.

Does the C++ spec guarantee initialization order? Or is any application that depends on it relying on undefined behaviour?

Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

#26

Post by londons_explore »

ectopod wrote: post #16
withinboredom wrote: post #10

Earlier quoted context omitted.

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.

You can bootstrap the compiler. It's a chore but not impossible. More usefully, you can check that your builds are identical to other people's, so at least your compiler isn't uniquely compromised.

> You can bootstrap the compiler. It's a chore but not impossible.

And specifically, only one person needs to do this once... I'm surprised there isn't some project doing this...

Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

#27

Post by withinboredom »

ectopod wrote: post #16
withinboredom wrote: post #10

Earlier quoted context omitted.

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.

You can bootstrap the compiler. It's a chore but not impossible. More usefully, you can check that your builds are identical to other people's, so at least your compiler isn't uniquely compromised.

I don’t think it’s possible since you’d need the original compilers from the 70’s and bootstrap other compilers up to a modern one. Otherwise your existing compiler could taint your new one.

Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

#28

Post by vlovich123 »

notpushkin wrote: post #22
vlovich123 wrote: post #5

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 ha…

For binary distributions, how about shipping object files and linking them on install with mold? This should be faster than compiling from source, just marginally slower than installing pre-linked binaries, and each build will be as unique as it gets.

The size of the distributed binary gets very large because you're shipping a lot of code that ends up getting eliminated by the linker. Also if you want to do any kind of LTO, then I don't see how you do it in your model. (which is significant for the larger applications like Chrome that have the likely attack surface). Not every binary on the system actually needs this either.

Finally, the main problem with this idea is that you can't audit malware because there's no way to maintain a source of truth about what the binary on a given system should be. Distributing randomly linked copies solves that because you can have a deterministic mapping based on machine characteristics (you do have to keep this hash secure but it's feasible). You'd basically be maintaining N copies of your distro with randomly built binaries with the user being given a random one to install.

And to be clear, my better idea is to do this at the compiler level so that you randomize the relative location of functions. That way it's impossible to find any gadget to grab onto and you have to get information leakage from the machine you're attacking & this information leakage has to be repeated for each machine you want to compromise.

Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

#29

Post by theg5prank »

londons_explore wrote: post #25
matzf wrote: post #17

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.

Does the C++ spec guarantee initialization order? Or is any application that depends on it relying on undefined behaviour?

There's no mandated order between compilation units. It's a problem significant enough to have its own snarky name: the Static Initialization Order Fiasco https://en.cppreference.com/w/cpp/language/siof

Re: Fun with Gentoo: Why don't we just shuffle those ROP gadgets away?

#30

Post by jchw »

blibble wrote: post #23
jchw wrote: post #15

Earlier quoted context omitted.

It's pretty much what OpenBSD is doing at bootup. Truthfully though you're right, using typical linkers, this would be pretty slow; at least a few seconds for large binaries, to minutes for things as large as web browsers. However, for many binaries, linking can be done much faster; mold claims to be only 50% the runtime of using `cp` on the object files, which is fast enough to even re-link Firefox on-the-fly withou…

I thought openbsd did it after boot?

Yeah. That said, I'm suggesting that if it was really too slow, though, it'd probably be infeasible to relink libc, the kernel, etc. at bootup. It's not a direct comparison to be sure.
Post reply on HN