Optimize native image memory location on Linux

[JohnChen0]

Currently on Linux, the native image for mscorlib (mscorlib.ni.dll) is loaded at a memory location far away from CoreCLR (libcoreclr.so). Since these two modules are over 2GB apart, all transitions between them have to go through indirect jumps. This creates a small performance penalty. CoreCLR should be modified to optimize where it loads native images.

[kangaroo]

We should be careful here. There are security tradeoffs. Do we want to ASLR native images?

I would vote yes.

[masonwheeler]

@kangaroo I've never actually seen a good explanation of how ASLR does anything to truly improve security.

Without ASLR: Attacker knows that TARGET_FUNCTION is located at address 0xABCDEF00, so he writes his attack code to jump to 0xABCDEF00.

With ASLR: Attacker doesn't know where TARGET_FUNCTION is located, because its location is no longer hard-coded. But in order for the program that links against TARGET_FUNCTION to be able to access it, it has to have a lookup in a hard-coded location that says where TARGET_FUNCTION is located. So that lookup is located at 0xFEDCBA00, and all the attacker has to do is write his attack code to use an indirect jump to the address found at 0xFEDCBA00. Unless the attacker is really squeezed for bytes... how does ASLR keep him out?

I've been asking this question for years now and never heard a good answer. Is there one?

[kangaroo]

@masonwheeler At a super quick explanation level: How does the attacker know that the PLT is at 0xFEDCBA00? Generally ASLR bypass requires walking from a controlled pointer to a vtable, or some other data structure with a known offset from the PLT. Additionally, more advanced ASLR can consider to reorder segments or PLT entries, etc to avoid that static constant offset.

[masonwheeler]

@kangaroo Sure, you can move things around, but at some point something has to exist at a static, known location, or pre-compiled code can't access it. And once that entry point exists... well, it's the same as the reason why DRM has never worked and never can: if a machine can read it, so can a programmer who can read machine code.

Am I missing something? I'll be the first to admit there's plenty I don't know, but as I understand it, ASLR doesn't actually put any mitigation in an attacker's path; it just throws around some indirections that act as speed-bumps. It feels to me more like "application security theatre" than "application security".

[kangaroo]

@masonwheeler Why does something have to exist at a static known location that persists between execution runs. The runtime linker can fix this for you. Does this mean that ASLR cannot be bypassed? No, but it does introduce a non-trivial amount of extra work to find an ASLR bypass. Of course this rapidly starts delving into the topic of ASLR applied to many things (segments, libraries, heaps, stacks), and is likely out of the scope of this specific issue.

That said, there is a non-academic reason why every major OS implements ASLR, and is actively trying to improve on it from release to release. CFI, SMAP, SMEP and other technologies probably throw up more effective barriers, but security is an onion.

Given CoreCLR has a server target focus, making 1 exploit that goes from $sp+[constant] to get to a ROP chain to gain execution would be very, very bad. We need careful consideration around issues like this.

Perhaps someone from the MS security team would like to chime in?

cc @richlander @jkotas @janvorli @sergiy-k

[janhenke]

I agree with @kangaroo. We should really support security technologies provided by the platform we are running on. Certainly there is no "perfect" security, but everything making it harder for an attacker is certainly something good.

[DemiMarie]

Just because mscorelib is near CoreCLR does not mean that the two need to be in the same relative location every time. Also, mscorelib is mostly verifiable managed code.

[gkhanna79]

@sergiy-k Is this still outstanding?

[sergiy-k]

This should be fixed by dotnet/coreclr#3218.