OSes
Instead of waiting for patch cycles, admins could simply shut down vulnerable functions before attackers get there
Linux kernel maintainers are considering giving admins a giant red emergency button to smash the next time another nasty vulnerability drops before patches are ready.
The proposed feature, named “Killswitch,” would let admins temporarily disable specific vulnerable kernel functions at runtime instead of sitting around waiting for fixes. The so-called patch was submitted by Linux stable kernel co-maintainer and Nvidia engineer Sasha Levin after a bruising couple of weeks for Linux security.
The proposal basically gives admins a way to pull the plug on vulnerable kernel functionality. If exploit code starts spreading before patches arrive, the targeted function can be disabled so calls to it immediately fail instead of reaching the vulnerable code.
“When a (security) issue goes public, fleets stay exposed until a patched kernel is built, distributed, and rebooted into,” Levin wrote. “For many such issues the simplest mitigation is to stop calling the buggy function. Killswitch provides that.”
The past couple of weeks have not exactly been great advertising for the traditional “wait for patches” approach.
First we saw the disclosure of CopyFail, a Linux local privilege escalation bug that quickly moved from disclosure to active exploitation. Days later, Dirty Frag emerged: another Linux privilege escalation flaw with public exploit code and no official fixes, after coordinated disclosure efforts fell apart before patches were ready.
As Levin’s proposal itself puts it, organizations are often left exposed “until a patched kernel is built, distributed, and rebooted into.” Killswitch aims to fill that gap.
Killswitch would work through the kernel’s security interface and is mainly intended for subsystems that systems can survive without for a while. In practical terms, Levin’s argument is that temporarily losing some networking or crypto functionality is preferable to leaving known vulnerable code exposed on production systems.
However, the feature would not fix vulnerable code or replace it with safe code. It just slams the door shut on the dangerous bit until administrators can properly update their kernels.
Naturally, handing sysadmins the ability to selectively shoot pieces of the kernel in the head has already sparked debate among developers over stability, potential for abuse, and whether people can be trusted not to accidentally saw off important limbs in production.
Still, after CopyFail and Dirty Frag, the kernel community increasingly seems to be arriving at the conclusion that running broken functionality may now be preferable to running weaponized functionality. ®
