[washbasin]

Please post a tl;dr at the top or even in the subject. Many of us are scrambling to patch/reboot our **.

[PunchyHamster]

tl;dr (not from article)

    echo -e 'install algif_aead /bin/false\n' > /etc/modprobe.d/disable-algif.conf 

that just prevents the faulty module from loading. So you have time to fix it properly (kernel upgrade)

Technically there should be zero impact (the very very few tools that use it will fall back to userspace), I haven't even found that module loaded in infrastructure

Then check if it is loaded, and if it is, unload/reboot

[mjmas]

Though this won't work for some kernels:

If algif_aead was a builtin module, it needs to be disabled by adding initcall_blacklist=algif_aead_init to the boot cmdline.

However initcall_blacklist requires the kernel to be built with CONFIG_KALLSYMS.

[chrisss395]

Dumb question: is preventing the module from loading safe to blindly run on, e.g., Unraid, Proxmox, WSL2? Is it possible to break anything?

[cpach]

I would say any sanely written application would fall back to doing the requested operations in userspace if it cannot use the AF_ALG socket.

It could fail though. But I have not yet heard of anyone noticing big problems due to disabling the problematic modules. And I have not noticed any such issues on our systems at ${DAYJOB}.

IMHO, since these parts of the Linux kernel are so crappy I personally would say disabling them is a good default choice. YMMV. But if you encounter problems, then you can always re-enable the modules. (Preferably after upgrading your kernel, obviously.)

[PunchyHamster]

check if module is loaded. if it isn't nothing is using it and you can safely add it. I'd also imagine most software doesn't fail but just use userspace lib

[atmosx]

tl;dr: switch to podman :-) or (for docker, not mention in the post but...) just `allowPrivilegeEscalation=False` in the deployment's SCC and you'll be fine at the pod level. Most deployments don't need priv escalation anyway, the ones that do need to either limits perms through capabilities or make sure the node (meaning the kernel) is patched.

[cpach]

How does allowPrivilegeEscalation=False help?

[atmosx]

Have you tested running the PoC in a pod with and without proviEsc set?

[cpach]

No, I haven’t.

My concern is to try to understand the mechanisms of the exploit.

Copy Fail is not simply ”hey, kernel, give me root”. I would say it’s more general than that. It’s rather: ”Hey, kernel, when you present file /foo to a process, make the contents of that file appear according to my wishes”. Which can be used (in various ways) to advance the attacker’s position.

That’s why I think it’s interesting to ponder if that power allows the attacker to simply sneak past security policies such as allowPrivilegeEscalation=false.

[isityettime]

It already has a table of contents. The heading titled "why rootless containers stopped the escalation" is your tl;dr.

[donaldjbiden]

This isn't a new CVE. It's just documenting what happened when this person ran the exploit inside a certain type of container.