How viable is a kernel exploit to actually do something? I would think by the time an attacked could actually use one they have already gotten pretty far.
How viable is a kernel exploit to actually do something? I would think by the time an attacked could actually use one they have already gotten pretty far.
Linux is full of local root exploits and while most script-kiddies just exploit your WordPress plugin and mine some coins or setup a DDoS script that works until someone notice it, having root and a rootkit on machines is probably the goal of any serious intruder - especially if it's servers on organisations and stuff like that.
It also means depeding on the exploit that you can escape Docker, LXC or even KVM/QEMU - rarely but it has been done.
Shared-hosting is, in practice, a high-trust environment, and trying to patch your way around that sounds like the snakeoil logic of Windows security products.
Might be true that it's not that important for the cloud crowd where you just use an instance for everything but that that's expensive and not the reality outside of certain bubbles and in the end the problem is just invible to you because Google or Amazon are tightening their hypervisors for you.
Lot's of Hadoop/HPC clusters or university desktops depend on this stuff.
With everyone moving to Docker and Containers the kernel is the only thing that prevents an intruder from owning the host or the cluster - it's a shame that this is not taken seriously - however they still assign CVEs for it.
On a modern cluster node you have software defined networking - having root on a node also means access to different VLANs and stuff like that - most distribued applications just blindly trust anything inside their internal network are a pain the secure (try setting up Hadoop with Kerberos, it's not exactly click&play). A normal setup gives you a SSH key and instant shell on every machine in the cluster.
Also most machines are identical so if you own one, you most probably have the means to own all. You can also get all the configuration management data as root.
It's for sure not a barrier you should use as your last stand but it's something that should be as hard as possible to overcome. Just giving up and saying who cares only makes the job for future intruders easier.
Prove it.
As I've said script kiddies probably fail at exploiting this but if you have valuable infrastructure to maintain and you've got someone talented or bored on the other side or even inside your network i.e. university networks where you can't reboot everything every other day it's not unrealistic.
First up, nearly half of this years priv esc bugs in Linux so far are specific to Android (and most of those involve things like nvidia drivers). That's serious, but not "somebody can get root on my server" serious.
Another handful of them are specific to some driver, some kernel module, or some kernel feature, that would only be used on a subset of systems. Still bad, but it does mean that at any given time, even systems running theoretically exploitable systems often won't be because the feature needed to exploit it isn't turned on and can only be turned on by root. For example, one of the high scoring vulnerabilities requires a user or process with CAP_NET_RAW capability. That has to be granted by root, and would presumably only be granted to trusted users and processes.
But, others are pretty scary and would be exploitable in a lot of cases. It's a reminder to stay on top of updates. And, also a reminder that the kernel is a huge surface area for attacks. It sometimes seems like a miracle that any of this stuff works at all.