- Synacktiv says full Linux exploit scripts have appeared days before patches were widely available, and that hardening can mitigate most recently published exploitation chains. These are the firm's own claims.
- It describes two controls: limit su and sudo to a trusted group, and let the kernel load only needed modules. Both are mitigations, not fixes, and both have operating costs.
- Leaders should have teams measure the gap between public exploit and patched reboot, and decide who owns testing when a module lockdown breaks a service.
Some of the most useful security work on a Linux server happens before anyone announces the bug. That is the heart of Synacktiv's defence-in-depth argument. A patch arrives on the vendor's schedule. A permission setting or a kernel switch is something your own team controls today.
What Synacktiv reports
Synacktiv, a security firm, says defenders face a weekly reveal of new critical Linux vulnerabilities. It says full exploit scripts have been made public days before patches are widely available. It attributes this partly to AI-assisted vulnerability research and to kernel patch diffing that breaks "responsible disclosure" embargoes.
These are the firm's observations. The post gives no count to back them. The firm also says most of the recently published exploitation chains can be mitigated by long-established hardening. That is Synacktiv's own assessment.
Synacktiv describes one case from its own fleet. When the Crackarmor flaws in the AppArmor security module became public on a Friday morning, it read Qualys' report. It concluded it had to patch many of its Debian systems. The patched kernel was not yet in Debian's repositories. But the firm's existing permission settings already covered the main attack route Qualys described, so its servers were not left bare while it waited.
How the first defense works: close the door on su and sudo
The main Crackarmor attack path Qualys described used the su command. A second scenario used sudo. Both are setuid programs, meaning they run with the powers of their owner, which is root. On default Debian and Ubuntu installs, any user can try to run them. That includes accounts such as ntpd, avahi or "nobody", which run network-exposed software.
Synacktiv changed the permissions so only root or members of a non-default "admins" group can run su or sudo at all. Other users cannot even open the file. The Qualys attack needs to run su, so it first requires a somewhat trusted user. Synacktiv says the public Copy Fail proof of concept also used su, so the same hardening could mitigate it.
This is a mitigation, not a fix. The kernel stays vulnerable until it is patched and rebooted. Synacktiv adds that another setuid program could in theory trigger the same flaw, though its researchers found none.
A plain chmod will not last. The next package update on Debian restores the default permissions. Synacktiv recommends dpkg-statoverride, the package manager's own way to make a permission change permanent. It says the command is easy to place in automation playbooks.
The second defense: stop the kernel loading what you do not use
Linux ships hundreds of optional kernel modules and loads them on demand when a program asks. Synacktiv says bugs have often been found in niche, less-audited modules. Unprivileged user namespaces, now on by default on major distributions, let ordinary users reach kernel code once open only to root.
Two recent exploits fit this pattern. Copy Fail uses AF_ALG sockets to reach the algif_aead module. Synacktiv says most software that uses it can fall back to other methods. Dirty Frag relies on flaws in the esp4 and esp6 modules, which implement IPsec. Unless a machine is an IPsec VPN gateway, Synacktiv says it probably does not need them.
Vendor advice is to block each affected module, and Synacktiv says that works. It argues for an allowlist instead: load only modules with a known reason to be there. The lightest route is the modules_disabled setting. Once boot has loaded the needed modules, root writes a 1 to it. The kernel then refuses new modules until the next reboot.
The trade-offs a leader should weigh
Both controls move cost from the attacker to your own operations team. The sources do not size that cost, so the judgments below are ours.
Take the su and sudo restriction first. Someone must own the admins group and decide who belongs in it. Anyone outside it loses the ability to run those commands. That suits servers with a small, stable set of administrators. It will need more care on shared machines where many people expect to use sudo.
The module lockdown costs more. Synacktiv warns that a program needing a module not yet loaded will fail. The error reads like "file not found", not "permission denied", so debugging misleads. The firm admits it takes trial and error. The lockdown also cannot be switched off at runtime, only by reboot.
In our view, this fits fleets of similar machines with predictable jobs, where one tested module list covers many servers. It fits less well where roles vary or change often. Synacktiv notes that custom kernels with only chosen modules are sound but not doable for everyone. Different system types would need different builds, and you take on patching yourself. It also sketches an eBPF-based approach, inspired by Cloudflare's Copy Fail response, as something that could be built.
What to ask your team
Start with the exposure window. Ask the team to measure the time from a public exploit to a patched kernel running after reboot, on a typical server. Synacktiv stresses that an unrebooted kernel stays vulnerable, so the clock runs until the reboot. If nobody can give that number, the window is unmanaged.
Then ask which users can run su and sudo, and whether the restriction survives package updates. Ask which kernel modules are loaded on production servers and which are needed. Ask which server groups are uniform enough for an allowlist. Finally, ask who owns testing when a lockdown breaks a service. The person paged at night will be the one decoding a misleading "file not found".
Synacktiv is clear that hardening does not replace patching. Its aim is to give defenders time. You cannot pick the day the next exploit lands, but you can decide how much it has to work with.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Synacktiv.
