FGKASLR Revved For Improving Linux Kernel Security

[phoronix]

Phoronix: FGKASLR Revved For Improving Linux Kernel Security

Intel open-source developer Kristen Carlson Accardi continues work on Function Granular Kernel Address Space Layout Randomization (FGKASLR) as a big improvement over traditional KASLR address space layout randomization...

http://www.phoronix.com/scan.php?page=news_item&px=FGKASLR-Linux-ASLR-V4

[tildearrow]

Typo: (should be base)

With FGKASLR, individual kernel functions are reordered so that even if the kernel's randomized based address is revealed, an attacker still wouldn't know the location in memory of particular kernel functions as the relative addresses will be different.

[elatllat]

if we bothered to adopt memory saifty ASLR would not be a thing.

[Danny3]

Sorry for my lack of better knowledge, but why is this randomization even needed ?
Isn't this something like "Security by obscurity" ?

Can't the whole memory access be controlled like a hotel in real life where each person can access only its own room for which he has received a key ?
It's that hard for the Linux kernel to just give to each program its own part of memory, part of hard drive and part of CPU or GPU and then don't let other programs to access what they are not supposed to ?

The whole moving stuff around and changing positions seems to me more like a hack than a real solution.
I guess I'm missing something, hopefully somebody has an answer that more of use can understand it.

[Almindor]

Sorry for my lack of better knowledge, but why is this randomization even needed ?
Isn't this something like "Security by obscurity" ?

Can't the whole memory access be controlled like a hotel in real life where each person can access only its own room for which he has received a key ?
It's that hard for the Linux kernel to just give to each program its own part of memory, part of hard drive and part of CPU or GPU and then don't let other programs to access what they are not supposed to ?

That's exactly how it works. However you also have a case of one guest leaving their faucet on and flooding the apartment underneath causing it's door to burst with all the water spilling the tenants stuff into the hallway as it does.

Randomizing the contents is like shifting the rooms as well as their contents into little pockets each time in a different configuration. Even if you have that leaky faucet attack you can't expect the right "stuff" to be spilled into public areas.

[ayumu]

No references to openbsd, which has had this feature for years, in the article?

[milkylainen]

Isn't this something like "Security by obscurity" ?

It is. Why? Because of default.

Humans will never stop putting their hands in the cookie jar.
Systems to prevent trespassing are not perfect.
Humans handling systems are not perfect.
Routines to handle systems are not perfect.

Never has been, never will be.
So we continue the arms race.
Into oblivion, without armistice in sight.

[Danny3]

That's exactly how it works. However you also have a case of one guest leaving their faucet on and flooding the apartment underneath causing it's door to burst with all the water spilling the tenants stuff into the hallway as it does.

Randomizing the contents is like shifting the rooms as well as their contents into little pockets each time in a different configuration. Even if you have that leaky faucet attack you can't expect the right "stuff" to be spilled into public areas.

Good explanation, but the "guest leaving their faucet on and flooding the apartment underneath..." wouldn't mean that some program can behave differently than expected and try to write more than the size of the slice of memory it was given to it ?
Can't this be controlled in a way like do not write into memory anything that more than the size you have been given an send back a message to the program to know that it has ran out of the allocated memory and what the program tried to write it was not written ?

While in real life is very difficult to have such a control not to flood anything, but I don't see why in computers cannot have a program like the hotel manager but for memory with a few simple duties like:

• Give each program a slice of memory and write into a table which program, location of slice and the size of it.
• When a program asks you to write something for it in its slice of memory, check in the above table if it's the owner of that slice and if there's enough space remaining in its slice to write that, so always write the data for the program until its slice is filled, but never more.
• When a program asks you to read something for it from its slice of memory, check in the above table if it's the owner of that slice and do it from one end to another, but never more that it has there.

In real life it would be possible to make all the faucets not working without the hotel manager itself turning them on or of so you' have to call him every time to do this, but it would insane and nobody would stay at such hotel, but in software, I don't see much of a problem moving the responsibility from programs to a trusted manager that does what they ask if they ask sane things.

[starshipeleven]

Sorry for my lack of better knowledge, but why is this randomization even needed ?
Isn't this something like "Security by obscurity" ?

Yes, but not all "security by obscurity" is bad.
I mean, soldiers aren't dressed in bright pink and tanks don't have neon lights all around them. Effective camouflage is a thing. All cooler aircraft are the "stealth" ones.

The bad kinds of "security by obscurity" is when the "obscurity" is bullshit like "it's in binary form" where any half-assed hacker can decompile and study it, or a secret that is known by a company's staff and can be stolen or shared.

In this case the kernel is randomizing stuff on runtime so only the kernel knows the secret, and the only way to know the secret is compromising the kernel, and the only way to compromise the kernel is defeating the randomization.

Now, there are papers about defeating specific KASRL implementations, and it's an arms race like everything else, so of course you need to keep developing and updating it as new ways to defeat it appear. But it is a valid layer of defence, it adds complexity to any attack.

It's that hard for the Linux kernel to just give to each program its own part of memory, part of hard drive and part of CPU or GPU and then don't let other programs to access what they are not supposed to ?

This is already what the kernel does (with memory/ram), and can do if set up correctly with SELinux/AppArmor (for other system resources).

The issue is that just like with people in a hotel, the restrictions aren't 100% perfect, sometimes there are bugs or ways to circumvent them and get the staffcard that opens all doors.
Hotel security is kind of crap actually, especially if they use cards, you can usually just clone the staff card by installing a sniffer inside the door's own lock and let the maid come and clean the room, because the door lock is 20$ bullshit from china and is just reading a plaintext number from the card, so any card with the same plaintext number is OK for it. Also it's not particularly hard to figure out a physical master key system if you have a non-master key, a blank key of the same brand and a hand file, but let's not get into that. Linux kernel isn't anywhere near as bad as physical security in most places.

But with an effective randomization in place, the application that broke free from the chains will have to employ logic to figure out where the kernel is storing the subsystems that you want to hack to actually get the job done (as in most cases you will want to overwrite or read some kernel parts in memory with your payload to have it do what you wanted), and this slows down the attack and requires more time and effort.

Kernel randomization is similar to truly randomizing the internal layout of the hotel to an extent that isn't really possible in real life like making it a non-euclidean space (i.e. one door opens to a room on first floor, and the next door opens to a room on the 8th floor for example, with memory addresses you can do that easily, in a physical building... much less), and removing all numbers so you don't know what door leads where. It's still possible to figure out where stuff is, but it's not really straightforward or quick anymore, especially because we are talking of tens of thousands of addresses, and not just a few dozen doors in the average hotel.

[starshipeleven]

In real life it would be possible to make all the faucets not working without the hotel manager itself turning them on or of so you' have to call him every time to do this, but it would insane and nobody would stay at such hotel, but in software, I don't see much of a problem moving the responsibility from programs to a trusted manager that does what they ask if they ask sane things.

This is what happens already and it is the entire point of having a kernel and not a single application running bare metal like in Arduino and other microcontrollers, or like what DOS and other simple OSes do (where each application has TOTAL control over the system until it decides to give it back to something else, and the concept of running two applications at once isn't a thing).

Applications are NOT accessing system hardware/resources directly but always asking the kernel to do stuff making system calls. The kernel can and will refuse to let them do things they aren't supposed to do (like snooping another process's memory) unless it was compiled/booted with debug flags (so you can run debug tools that do just that).

The problem is that we are not in 1999, the interfaces and logic doing the jobs requested are pretty complex and aren't perfect. Sometimes there are bugs that allow applications more control than they should be allowed to.

Another way to harden the kernel is to use languages like rust where some types of mistakes are simply not possible because the language does not allow do do that to begin with. Which is why there are fans of "rewrite everything in rust".