Earlier quoted context omitted.
Only for your user, and it means a keylogger on the system if it gets rooted can't pull your password to try on other machines. Personally I always either login as root or use passwordless sudo.
Yubikeys are also surprisingly annoying when setup for the as well. A working developer just needs sudo a lot. Realistically a "sudo button" would be handy, on the keyboard, with a display to show a confirmation pin for the request (probably also needs a deny button so you can try and identify weird ones).
Copy Fail
461–470 of 545 posts
Re: Copy Fail
#462Earlier 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`)
Sibling comment says this version seems to be immune.
Re: Copy Fail
#463Earlier quoted context omitted.
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).
Re: Copy Fail
#464Earlier quoted context omitted.
Only for your user, and it means a keylogger on the system if it gets rooted can't pull your password to try on other machines. Personally I always either login as root or use passwordless sudo.
Yubikeys are also surprisingly annoying when setup for the as well. A working developer just needs sudo a lot. Realistically a "sudo button" would be handy, on the keyboard, with a display to show a confirmation pin for the request (probably also needs a deny button so you can try and identify weird ones).
Re: Copy Fail
#465It'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…
Re: Copy Fail
#466It 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…
Good lesson in how not to do disclosure.
Re: Copy Fail
#467Earlier quoted context omitted.
It's just lazy AI* writing w/0 editing. "Just" is doing a lot of work there, I'm so annoyed reading it. It's like an anti-ad and they had pretty cool material to work with. * Claude loves stacatto "Some numeric figure. Something else. Intensifier" (ex. the "exploitable for a decade." or whatever sentences)
I recommend reading the technical writeup https://xint.io/blog/copy-fail-linux-distributions
Re: Copy Fail
#468Re: Copy Fail
#469Earlier quoted context omitted.
I hope they sell a lot of Xint Code licenses, so they don't have to sell their findings.
Considering they kinda botched the disclosure to Linux distros, I guess they wanted something most sensational to sell more licenses.
Re: Copy Fail
#470Earlier quoted context omitted.
Writing something by hand requires effort and signals seriousness. It's not unreasonable to take things less seriously when they come wrapped in low-effort packaging.
Sometimes that effort is better spent on other things.
I'm sure that, at first glance, many more people would take this much more seriously had the authors gone with a style-less HTML page or something, and that'd require _less_ effort, not more.