Linux 5.13 Lands Support For Randomizing Stack Offsets Per Syscall

[phoronix]

Phoronix: Linux 5.13 Lands Support For Randomizing Stack Offsets Per Syscall

One of the new security features in Linux 5.13 is the ability to randomize kernel stack offsets at each system call. This optional feature is now mainlined...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Rand-Offset-Sys-Call

[marios]

Taking a 1% performance hit in order to make it harder (but still doable) for an attacker to exploit a vulnerability (that already exists)... Looks like beyond stupid to me...

[timofonic]

Taking a 1% performance hit in order to make it harder (but still doable) for an attacker to exploit a vulnerability (that already exists)... Looks like beyond stupid to me...

How would you make it better then? Patches welcome

[marios]

How would you make it better then? Patches welcome

At least I would not make it worse. This patch just adds some performance overhead without improving security (it does not kill vulnerabilities, it just makes the attacker work harder in order to exploit them).

[Zan Lynx]

I have not looked into this particular thing. But, just because it does not make it impossible to use a vulnerability does not make it useless. Most of these will cause a crash when an attacker calls into a missing address. The randomization does not make this impossible but it does cause a large number of crashes and log messages which should alert the security team. Or one admin, as the case may be.

Anything that turns a silent invisible attack into a noisy one is a good thing.

[oiaohm]

At least I would not make it worse. This patch just adds some performance overhead without improving security (it does not kill vulnerabilities, it just makes the attacker work harder in order to exploit them).

Its not only harder to exploit the exploits. It harder to use the exploits without having them logged in HIDS (Host Intrusion Detection System) or NIDS (Network Intrusion Detection System) so leading to security teams looking into it.

This does not kill the vulnerability directly but shorten down the amount of time exploit can be used without being detected then finally fixed. Sometimes this randomisation will take a sure exploit that will work 100 percent of the time mostly unable to be detected to a exploit that you have a better chance of winning the loto and every time it fails you are sending a alert message about this exploit.

Making attacker be noisy historic security thing. Think tripwrire with bells on. Yes tripwire with bells vs no tripwire does not stop the attacker being there or the exploit at that location being there but it does make it a lot more risky for the attacker that the tripwire is there because may to alert the protection force. Is a tripwire with bells a security item yes. Is tripwire with bells the best security item absolutely no fixing the flaw in security at that location is better.

So saying without improving security is wrong. Making attackers life harder does improve security and does make unknown vulnerabilities more discoverable and with the vulnerabilities discovered they then can be fixed.

I would class this 1 percent overhead 100 percent acceptable for a honey pot trap system so that you get more output data when the system is hit. Yes this is also a case we don't setup bell tripwires all the way around our house normally. So a feature like this one I would not expect to be for general systems but this does not mean the Linux kernel should not have this feature for particular systems that need higher sensitivity to unknown security issues.

[CochainComplex]

Performance over security was already not a good move with Intel CPUs...1% is not that much. One could argu if it should be enabled by default and then give the possibility to manually disabled it with kernel Boot parameters. Or the other way around.

[NathanG]

If your servers like many others are well under utilised a 1% hit isn't a major issue, especially for high security deployments. As others have said a high chance of noise by an attack on a quiet system is a very good thing.

[marios]

What specific vulnerability are you talking about though? You don't know do you?

The patch is not about a specific vulnerability. It is a generic "If there is a vulnerability an attacker might have to work harder to exploit it".

[jacob]

Taking a 1% performance hit in order to make it harder (but still doable) for an attacker to exploit a vulnerability (that already exists)... Looks like beyond stupid to me...

Memory protection, access control, firewalling etc. all have a much higher performance impact.