Hardening ELF binaries using Relocation Read-Only (2019)
1–10 of 31 posts
Re: Hardening ELF binaries using Relocation Read-Only (2019)
#2Glad to see this security by default progress from RedHat. I was surprised to not see a discussion of the costs, though. How much slower is program startup for large programs now that all these functions are unconditionally looked up at the start instead of lazily? Even functions that are never called are now looked up.
Re: Hardening ELF binaries using Relocation Read-Only (2019)
#3One might wonder how high this raises the bar; that is, what how an attacker would generally respond to full RELRO. The answer is usually that one would go after other data pointers not secured by RELRO. If there’s any in the binary, that’s the best, but otherwise usually you leak information about libc and target something like the malloc or free hooks which are likely to be called.
Re: Hardening ELF binaries using Relocation Read-Only (2019)
#4Glad to see this security by default progress from RedHat. I was surprised to not see a discussion of the costs, though. How much slower is program startup for large programs now that all these functions are unconditionally looked up at the start instead of lazily? Even functions that are never called are now looked up.
There’s a one sentence nod to this at the bottom:
> Using full RELRO has a slight performance impact during application startup (as the linker has to populate the GOT entries before entering the main function).
In general, the difference for a large application is non-negligible and one should carefully consider the impact before enabling this feature by default.
Re: Hardening ELF binaries using Relocation Read-Only (2019)
#5last time I checked the Debian and Gentoo hardening guides relro/pie were standard practice. I can't remember the time we didn't use it and I've been around for a minute.
this is my template for most Linux projects (except when "something else" is needed :)) ... please don't copy paste without certainty of what it does:
CFLAGS_BASE := -c -O2 -Wall -Werror -Wpedantic -pipe $(CFLAGS)
CFLAGS_HARD := -fPIE -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -fcf-protection -Wimplicit-fallthrough -D_FORTIFY_SOURCE=2
CFLAGS_DEBUG := -g3 -gdwarf-2
CFLAGS_RELEASE := -s -fomit-frame-pointer -march=native
LDFLAGS := -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,-pie -Wl,--no-copy-dt-needed-entries
LDFLAGS_HMALLOC := -L/usr/local/lib -lhardened_malloc # see https://github.com/GrapheneOS/hardened_malloc
Re: Hardening ELF binaries using Relocation Read-Only (2019)
#6Here is a video where Andreas implements RELRO protection in SerenityOS:
This might not be exactly the same as how it is implemented in Linux but at least to me seeing all the code involved from start to finish is a much better way to understand the concept.
Re: Hardening ELF binaries using Relocation Read-Only (2019)
#7Glad to see this security by default progress from RedHat. I was surprised to not see a discussion of the costs, though. How much slower is program startup for large programs now that all these functions are unconditionally looked up at the start instead of lazily? Even functions that are never called are now looked up.
There’s a one sentence nod to this at the bottom: > Using full RELRO has a slight performance impact during application startup (as the linker has to populate the GOT entries before entering the main function). In general, the difference for a large application is non-negligible and one should carefully consider the impact before enabling this feature by default.
> In general, the difference for a large application is non-negligible and one should carefully consider the impact before enabling this feature by default.
And because of that they enabled it for all binaries on Fedora. The fedora users are now testing whether it's possible to activate it by default.
Re: Hardening ELF binaries using Relocation Read-Only (2019)
#8last time I checked the Debian and Gentoo hardening guides relro/pie were standard practice. I can't remember the time we didn't use it and I've been around for a minute. this is my template for most Linux projects (except when "something else" is needed :)) ... please don't copy paste without certainty of what it does: CFLAGS_BASE := -c -O2 -Wall -Werror -Wpedantic -pipe $(CFLAGS) CFLAGS_HARD := -fPIE -Wformat-secur…
Wouldn't some of this be mitigated by specifying function visiblity? AIUI, when building a shared lib, all functions are visible in case a user wants to hook any functions via, e.g. LD_PRELOAD
Re: Hardening ELF binaries using Relocation Read-Only (2019)
#9Glad to see this security by default progress from RedHat. I was surprised to not see a discussion of the costs, though. How much slower is program startup for large programs now that all these functions are unconditionally looked up at the start instead of lazily? Even functions that are never called are now looked up.
There’s a one sentence nod to this at the bottom: > Using full RELRO has a slight performance impact during application startup (as the linker has to populate the GOT entries before entering the main function). In general, the difference for a large application is non-negligible and one should carefully consider the impact before enabling this feature by default.
From security assessment of view, I consider the impact as being the monetary damage that might happen if an exploit is taken advantage of.
Naturally one might consider it doesn't matter for the use case at hand.
Re: Hardening ELF binaries using Relocation Read-Only (2019)
#10last time I checked the Debian and Gentoo hardening guides relro/pie were standard practice. I can't remember the time we didn't use it and I've been around for a minute. this is my template for most Linux projects (except when "something else" is needed :)) ... please don't copy paste without certainty of what it does: CFLAGS_BASE := -c -O2 -Wall -Werror -Wpedantic -pipe $(CFLAGS) CFLAGS_HARD := -fPIE -Wformat-secur…
Isn’t -gdwarf-2 an odd choice? Wouldn’t you prefer one of the newer, more expressive flavors of DWARF? -g by itself gets you the default, which is newer than 2 (at least for clang).