3 ms·

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

nullsanity 5mo ago
[dead]
donaldjbiden 5mo ago
This isn't a new CVE. It's just documenting what happened when this person ran the exploit inside a certain type of container.
isityettime 5mo ago
It already has a table of contents. The heading titled "why rootless containers stopped the escalation" is your tl;dr.
PunchyHamster 5mo ago
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
- chrisss395 5mo ago
  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 5mo ago
    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 5mo ago
    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
- mjmas 5mo ago
  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.
atmosx 5mo ago
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 5mo ago
  How does allowPrivilegeEscalation=False help?
  - atmosx 5mo ago
    Have you tested running the PoC in a pod with and without proviEsc set?
    - cpach 5mo ago
      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.

[dead]

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

isityettime 5mo ago

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

PunchyHamster 5mo ago

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

chrisss395 5mo ago
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 5mo ago
  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 5mo ago
  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
mjmas 5mo ago
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.

atmosx 5mo ago

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 5mo ago
How does allowPrivilegeEscalation=False help?
- atmosx 5mo ago
  Have you tested running the PoC in a pod with and without proviEsc set?
  - cpach 5mo ago
    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.