[dead]
Copy Fail
251–260 of 545 posts
Re: Copy Fail
#252Tried this on my arch VPS which has a few users that hasn't been rebooted for 122 days.
Got:
OSError: [Errno 97] Address family not supported by protocol
Edit:
Looks like on Arch you have to go out of your way to have this enabled.
$ zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_USER_API_RNG=m
# CONFIG_CRYPTO_USER_API_RNG_CAVP is not set
CONFIG_CRYPTO_USER_API_AEAD=m
# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
$ uname -r
6.12.63-1-ltsRe: Copy Fail
#253As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. Th…
As I did not know what AF_ALG is in the first place I've searched for it and found this here:
https://www.chronox.de/libkcapi/html/ch01s02.html
It states the following:
> There are several reasons for AF_ALG:
> * The first and most important item is the access to hardware accelerators and hardware devices whose technical interface can only be accessed from the kernel mode / supervisor state of the processor. Such support cannot be used from user space except through AF_ALG.
> * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters are handed to the kernel. The calling application now can reliably erase that information from its memory and just use the cipher handle to perform the cryptographic operations. If the application is cracked an attacker cannot obtain the key material.
> * On memory constrained systems like embedded systems, the additional memory footprint of a user space cryptographic library may be too much. As the kernel requires the kernel crypto API to be present, reusing existing code should reduce the memory footprint.
I can't judge whether this is a good justification, but there is one.
Re: Copy Fail
#254Good thing nobody is silly enough to let fully autonomous AI agents run as regular users on these affected operating systems. That could be disastrous given a zero day prompt injection technique.
Good thing we haven't normalized installing things with curl | sh
I literally ship an installer that runs with curl | bash... reading this thread while patching my servers is a fun experience lol
Re: Copy Fail
#255The Python dependency is easily eliminated, and the x86_64 payload made cross-platform: https://github.com/tgies/copy-fail-c
Re: Copy Fail
#256It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros. https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred" https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-3143…
It was already known to attackers (or basically anyone watching) weeks ago when the patch hit the kernel but it wasn't communicated by upstream as a vuln (because Linus and Greg do not believe that vulnerabilities are conceptually relevant to the kernel).
Will this continue like that even when the prophesied Mythos Vulnocalypse hits the Kernel?
This stance doesn't seem sustainable any more to me.
Re: Copy Fail
#257Earlier quoted context omitted.
It was already known to attackers (or basically anyone watching) weeks ago when the patch hit the kernel but it wasn't communicated by upstream as a vuln (because Linus and Greg do not believe that vulnerabilities are conceptually relevant to the kernel).
Will this continue like that even when the prophesied Mythos Vulnocalypse hits the Kernel? This stance doesn't seem sustainable any more to me.
The response from Greg was that Mythos proved that upstream was right all along and that they'll continue to do things the same way. That's my recollection, at least - pretty sure it was something like that, could have been even worse though and I'm misremembering.
The stance was never sustainable, hence linux LPEs being constantly available. The solution is to treat your kernel as impossible to secure. Notably, gvisor users are not impacted by this CVE. Seccomp also kills this CVE.
Re: Copy Fail
#258Anyone have any idea when Bottlerocket will acknowledge CVE? Seems like a critical for kubernetes nodes......
https://github.com/bottlerocket-os/bottlerocket/security/adv...
Re: Copy Fail
#259As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. Th…
How did it get in? Isn’t Linus known for being rightfully fussy about what makes it into the kernel?
Would be an interesting story.
Re: Copy Fail
#260Earlier quoted context omitted.
Will this continue like that even when the prophesied Mythos Vulnocalypse hits the Kernel? This stance doesn't seem sustainable any more to me.
The response from Greg was that Mythos proved that upstream was right all along and that they'll continue to do things the same way. That's my recollection, at least - pretty sure it was something like that, could have been even worse though and I'm misremembering. The stance was never sustainable, hence linux LPEs being constantly available. The solution is to treat your kernel as impossible to secure. Notably, gvis…
How about SELinux, like on Android?