Same here, zero plugins for me.

Regarding su…

  su -

might yield better results.

Does anyone know how to mitigate this one? Is it sufficient to disable the esp4/esp6/rxrpc modules?

Main discussion here: https://news.ycombinator.com/item?id=48058393

Welcome to Hacker News! Please write in English here. Thank you in advance from a long-time member :)

Translating the comments and looking at the bio, wouldn’t be surprised if this is a bot.

Sure. But it would probably still be a good thing if the kernel maintainers could tear out AF_ALG.

How does allowPrivilegeEscalation=False help?

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

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.

How?

--userns=auto asign a different namespace for each container, so if you escape it you get a random uid far far away from root it also protects other containers from the compromise since they each have their own namespace and uid/gid range, the drawback though is that you can't mount shared volume unless you use a pod, since you would see files from outside your uid/gid range as owned by nobody and inaccessible.

That might make Copy Fail harder to exploit, but I still wouldn’t bet money on CF being impossible to use in that scenario.

Since in --userns=auto, root inside the container gets assigned to the first uid of the uid range assigned by podman, copyfail would succeed but you'd get uid 647831 and be able to do nothing with it

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.)

Good enough for what?

I could be wrong, but I’m not sure those settings are enough to mitigate Copy Fail.

If your distro offers a patched kernel, it’s best to upgrade to that one and reboot.

You can also disable the vulnerable module (how to do it depends on what distro you’re using). But if you stay on an old unpatched kernel you might be exposed to other vulnerabilites.

You are misinterpreting my goal here. I have patched my kernel against copy fail but I am thinking of ways to harden my setup against future CVEs in the kernel.

So the question is, before I learned about copy fail, what could I have done that would have limited the possible damage this vulnerability could do to me? CapabilityBoundingSet is one answer and rootless podman as mentioned in this article is another. They don’t prevent all but at least `su` is useless.

If so, I would look into applying a decent seccomp profile.

Other hardening solutions could be to run the workloads inside of a VM such as Firecracker, or gVisor. But that might be more work to implement compared to seccomp.