2 ms·

But where in its own binary? To support ASLR of code (a ROP mitigation), especially fine-grain randomization, function call sites can't use static addressing, e

by wahern 6y ago

But where in its own binary? To support ASLR of code (a ROP mitigation), especially fine-grain randomization, function call sites can't use static addressing, either absolute or relative, pointing directly to a function. To support ASLR of code you can either rewrite every function call site on load (kinda similar to DLLs on Windows), or use one or more tables that are updated at runtime (PLTs, GOT, etc). BSD and Linux environments use the PLT/GOT approach because 1) it's a better fit for ELF, 2) shares most of the preexisting instrumentation with dynamic linking, and 3) preserves the ability to share most of the mapped pages of static binaries (imagine if a static /bin/sh was effectively rewritten on every invocation). Trying to accomplish this safely and effectively is what RELRO is about. See https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro https://www.redhat.com/en/blog/hardening-elf-binaries-using-... But RELRO poses some dilemmas regarding performance, and depending on your choices as well as the details of the implementation, RELRO might be ineffective or, worse, introduce exploits of its own. See https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-di-frederico.pdf https://www.usenix.org/system/files/conference/usenixsecurit... It's difficult to achieve a design that provides all the desirable exploit mitigations without sacrificing startup latency and other features. OpenBSD added a new syscall, kbind (https://man.openbsd.org/kbind https://man.openbsd.org/kbind), so that they can have lazy binding without being susceptible to the RELRO exploits mentioned in that Usenix paper. (Unfortunately, the 2018 leviathansecurity.com article fails to mention kbind, even though kbind was added to OpenBSD in 2015.) There are other approaches. I think the PaX Team has written quite alot about their preferred techniques. But the point is that static PIE, which is desirable because of ASLR and other reasons (e.g. unification of code generation techniques), touches upon varying and distant components of toolchains and runtimes.

saagarjha 6y ago
I know how ASLR/ROP/PLT/GOT/RELRO work, but I'm still not understanding what's going on here. When you statically link a binary, you get…one file. And that gets loaded into memory together, and to make it PIE you have all the jumps be pc-relative. Like, a straight up jump instruction to a fixed offset. So where the the room for a table like this? (Unrelated, but since you brought it up: kbind is IMO not a very good mitigation. It seems that all you have to do to bypass it is leak a cookie and ROP to that one place in ld.so that is "blessed" and then you not only have the ability to scribble all over your read-only GOT but as far as I can tell you can overwrite any read-only memory, which means it opens up an extremely valuable exploit primitive…)
- spc476 6y ago
  When I participated in NaNoGenMo 2015 [1], I ended up having to emulate a very small subset of MS-DOS [2]. That meant loading in an MS-DOS `.EXE` file into memory and running it. I had a 32-bit Linux system, so I was able to use the `vm86()` system call to run the 16-bit code natively. The `.EXE` file had basically two sections---the first the actual binary code (and data and what have you). This was followed by another section that contained offsets into the code that was loaded that needed to be updated with the proper address, and it took all of five lines of code to implement [3]. Once used, that segment can be discarded. You don't need position independent code to implement address space layout randomization (it makes it easier), you just need a table to rework the absolute addresses (downside---it may take some time). [1] National Novel Generation Month [2] https://github.com/spc476/NaNoGenMo-2015 https://github.com/spc476/NaNoGenMo-2015, specifically, https://github.com/spc476/NaNoGenMo-2015/blob/master/C/msdos.c https://github.com/spc476/NaNoGenMo-2015/blob/master/C/msdos... [3] lines 337 to 343 of `msdos.c` [2]
  - saagarjha 6y ago
    This isn’t my area of expertise, but I think on Windows relocations are actually handled quite similarly (as a table of locations that the loader uses to patch with).
  - account42 6y ago
    Relocation by patching code means you no can no longer share code sections between programs.
- wahern 6y ago
  Turns out I was the confused one, not you. I thought it was at least possible to generate binaries with multiple segments, each with their own PLT, GOT, and .text sections, similar to putting .text and .data sections in separate segments. That way the relative position of all functions wouldn't be static. But it seems there's no way to generate binaries like this using the standard tools.

by wahern 6y ago

saagarjha 6y ago

I know how ASLR/ROP/PLT/GOT/RELRO work, but I'm still not understanding what's going on here. When you statically link a binary, you get…one file. And that gets loaded into memory together, and to make it PIE you have all the jumps be pc-relative. Like, a straight up jump instruction to a fixed offset. So where the the room for a table like this? (Unrelated, but since you brought it up: kbind is IMO not a very good mitigation. It seems that all you have to do to bypass it is leak a cookie and ROP to that one place in ld.so that is "blessed" and then you not only have the ability to scribble all over your read-only GOT but as far as I can tell you can overwrite any read-only memory, which means it opens up an extremely valuable exploit primitive…)

spc476 6y ago
When I participated in NaNoGenMo 2015 [1], I ended up having to emulate a very small subset of MS-DOS [2]. That meant loading in an MS-DOS `.EXE` file into memory and running it. I had a 32-bit Linux system, so I was able to use the `vm86()` system call to run the 16-bit code natively. The `.EXE` file had basically two sections---the first the actual binary code (and data and what have you). This was followed by another section that contained offsets into the code that was loaded that needed to be updated with the proper address, and it took all of five lines of code to implement [3]. Once used, that segment can be discarded. You don't need position independent code to implement address space layout randomization (it makes it easier), you just need a table to rework the absolute addresses (downside---it may take some time). [1] National Novel Generation Month [2] https://github.com/spc476/NaNoGenMo-2015 https://github.com/spc476/NaNoGenMo-2015, specifically, https://github.com/spc476/NaNoGenMo-2015/blob/master/C/msdos.c https://github.com/spc476/NaNoGenMo-2015/blob/master/C/msdos... [3] lines 337 to 343 of `msdos.c` [2]
- saagarjha 6y ago
  This isn’t my area of expertise, but I think on Windows relocations are actually handled quite similarly (as a table of locations that the loader uses to patch with).
- account42 6y ago
  Relocation by patching code means you no can no longer share code sections between programs.
wahern 6y ago
Turns out I was the confused one, not you. I thought it was at least possible to generate binaries with multiple segments, each with their own PLT, GOT, and .text sections, similar to putting .text and .data sections in separate segments. That way the relative position of all functions wouldn't be static. But it seems there's no way to generate binaries like this using the standard tools.