Does anyone have a workaround for it? Edit: I don't understand why the comment would be downvoted.
There's some workarounds in https://copy.fail/#mitigation
Copy Fail
421–430 of 545 posts
Re: Copy Fail
#422Earlier quoted context omitted.
But is it true or not? Whoever wrote it. (for objective truth the subjects are unimportant)
When you can’t know the objective truth or when there isn’t one (as is the case in making decisions about security tradeoffs in software design), knowing the source of the argument is vital to interpreting its validity.
I disagree 100%. Software security tradeoffs are definitely the sort of thing where you can evaluate arguments on their merits.
Re: Copy Fail
#423Earlier quoted context omitted.
can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum
Isn't the better argument to ask whether there'd be benefit if all those things did? A lack of adoption isn't apriori a good argument against an interface, and serious bugs can happen anywhere. My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers…
> A lack of adoption isn't apriori a good argument against an interface
I mean it kind of is (perhaps not a priori, but why is that relavent?). If something is not being used, its not meeting needs, so its just increasing attack surfaces without benefit.
Re: Copy Fail
#424So this replaces a SUID binary, in order to run as PID 0. The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container (or specifically, a user namespace). I ran the exploit in rootless Podman, and predictably it doesn't escape the container. They also claim their script "roots every Linux distribution shipped…
[flagged]
Re: Copy Fail
#425Earlier quoted context omitted.
can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum
Isn't the better argument to ask whether there'd be benefit if all those things did? A lack of adoption isn't apriori a good argument against an interface, and serious bugs can happen anywhere. My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers…
> My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers were invented.
There’s a valid argument here but I think that’d devolve into the DNSSec trap without both a very well-designed API and a stable way to ship updates for older kernels. If people can’t get good user experience or have to force kernel upgrades to improve security, most applications will avoid it. Things like Chrome shipping their own crypto mean that they can very quickly ship things like PQC without waiting years or having to deal with issues like kernel n+1 having unrelated driver or performance issues which force things into a security vs. functionality fight.
Re: Copy Fail
#426Note that in kubernetes, setting `allowPrivilegeEscalation` to false (which you should be doing already, it's in the Pod Security Standards Restricted profile) mitigates this.
Re: Copy Fail
#427LPE = local privilege escalation Too many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!
LPE is a very well-known acronym within the security community, it's not purely academic or obscure or anything. I agree that it would be a good idea to define it explicitly when writing for a broader audience, but I don't think it's particularly egregious that they didn't. It's certainly something I could see myself forgetting. Then again, the whole writeup appears to be AI-generated, so...
It is nowhere near this. There are very few acronyms in the IT world that are actually well-known outside of it. LPE is less well-known than LVAD or MCU.
https://www.acronymfinder.com/Information-Technology/MCU.htm...
https://www.acronymfinder.com/LVAD.html
https://www.acronymfinder.com/Information-Technology/LPE.htm...
Re: Copy Fail
#428Earlier quoted context omitted.
Oddly, the POC doesn't work on my Debian 12 (Bookworm) EC2 instance. Everything that should indicate it's vulnerable is there, including the ability to socket(38,5,0).bind("aead", "authencesn(hmac(sha256),cbc(aes))")
What kernel version is it? (`uname -r`)
Not the OP, but I've tried it on Debian 12 and kernel 6.1.0-34-amd64 is vulnerable (ie. the exploit works) but 6.1.0-42-amd64 and 6.1.0-44-amd64 seem to be immune, at least for me. I have only tested the exploit as-is (with su). I do see from other comment theads here that someone had it work for them on 6.1.0-43, but I can't yet find that kernel installed anywhere here to verify.
Re: Copy Fail
#429It's unfortunate that this does not include which versions of the kernel are vulnerable/patched, especially since this is a builtin module which cannot be easily removed with rmmod... I was wondering if I was vulnerable running Fedora 44, kernel 6.19.14, and after a few minutes of digging I was able to find the linux-cve-announce mailing list post: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20... which…
Greg KH says more backports coming soon.
Re: Copy Fail
#430Earlier quoted context omitted.
To even get the su binary on Android you have to patch the OS. So this exploit can't work on Android. Because there is no su binary to target. Update: Just tried it on Termux and as expected even creating an AF_ALG socket requires root access.
The specific exploit payload for the POC relies on a su binary. The vuln is ambivalent and other non-su paths will exist.
Of course, but it does not matter as the entire AF_ALG module is forbidden by SELinux anyway (on Android).