Just kicking trying to manage my CopyFail nausea.
Post
Long fingers today, in many machines. Dozens of services patched, host machines alongside.
I've typed `uname -a` a great many times in my life, but I don't think as many in one day.
Debian's patched 6.12.85+deb13-amd64 #1 SMP PREEMPT_DYNAMIC seems GTG with the PoC published here:
https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/main/copy_fail_exp.py
```
root@cake:~# su - eat
eat@cake:~$ vim foo.py
eat@cake:~$ cat foo.py | python3 && su
Password: su: Authentication failure
Password:
```
Bit worried about where Ubuntu is at. Ominously, their own fix announcement page seems down:
https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available
@ctoney sent through this helpful update. It appears Ubuntu web infra might be under DDoS rn https://status.canonical.com/
A bit odd. Ubuntu's status page currently looks like this.
If this is a DDoS, it is a very expensive one. Someone with a lot of money and spite.
I went through a bunch of VMs post patch and found one that had algif_aead loaded & so the PoC passed.
If that module is loaded, you're still vulnerable.
EDIT, for Debian family:
Blacklist like so:
```
modprobe -r algif_aead
```
Then put this into a /etc/modprobe.d/blacklist-aead.conf:
```
blacklist algif_aead
install algif_aead /bin/false
```
Then:
```
/sbin/update-initramfs -u -k all && reboot -n
```
@JulianOliver
Regarding the workaround: how is blacklisting of this module useful? Is it normally loaded through an alias? I saw no alias in modinfo.
BTW: if modprobe fails, it will give the full command line. So you can give a custom error message to modprobe to show up in the logs:
install algif_aead /bin/false Loading of module algif_aded disabled in /etc/modprobe.d/blacklist-aead.conf
(false ignores its command line)
@tzafrir I found edge cases where the PoC actually triggered module load. `lsmod` showed no module before, but was present immediately after execve() & priv escalation.
Blacklisting and then `install` to /bin/false
is a crude but safe-than-sorry fix until something sane comes along.
@tzafrir Here is an example
@JulianOliver
What I meant is:
The 'blacklist' line had no effect.
I ran the relevant part of the above python code as root to trigger loading the module. Adding a blacklist line alone had no effect on preventing a load of it. Adding an install line did have an effect.
@tzafrir the blacklist line is just there so the module will not load on boot, to be leveraged by an attacker later. The install line will ensure that if ever it is loaded by hotplug or manually later, it will fail anyway.
You could indeed just have the install line but might as well have both to avoid it even attempting to load on boot for those edge cases.
There are a bunch of ways to do it, with same end outcome.
EDIT: fixed a logical confusion I made regarding hotplugging. TY @tzafrir
@JulianOliver
Again, blacklist has no effect when a module is loaded with 'modprobe $module_name'. It only has effect if an attempt is made to load a module through an alias.
When you probe (hotplug or coldplug) all the devices on a bus, the kernel will attempt to load them through aliases (e.g.: vendor ID and product ID on PCI bus). Those in practice are registered as aliases of the kernel module.
But algif_aead is loaded through a direct
request_module("algif-%s"
in crypto/af_alg.c .
@JulianOliver dedication to the nth degree
@kategenevieve Phew, doing my best at least. I had other plans for today argh!
@JulianOliver ha ha ha the computers don't care about your human plans. they need *all* your time.
You could disallow the specific crypto module, if it is compiled as a module rather than into the main
... but don't extend your class to include "here's how to recompile your kernel"!!!
@futuresprog Hehe, I would have to add a day for that!
This distros I work with have been very quick to patch, and so I currently have fingers in many servers, and their many guests, getting them sorted. TBH I had different plans for today, but such is #sysadminlife
@JulianOliver Have you considered doing a Fortress session with OpenBSD or FreeBSD?
@pertho FreeBSD I have yes. The tricky bits come down to ease of use on the hypervisor. More so most or all of the guests themselves would need to be GNU/Linux due to going with official deploys for the services they host. I would also need to do the pre-training (Tunnel) on a *BSD also, to get people in the zone.
One for the future. Would be great. Just raises the entry barrier a little, maybe making for longer sessions.
@JulianOliver @pertho This would be neat - I keep a FreeBSD host at home and I get the occasional temptation to rebuild with jails and full ZFS. Still <3 debian though.