Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Copy Fail

copy.fail

Post reply on HN
Print view View original

471–480 of 545 posts

Re: Copy Fail

#471

Post by baggy_trough »

stefanor wrote: post #466
xeeeeeeeeeeenu wrote: post #82

It 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…

As far as we can tell, nobody disclosed it to the distributions, only to the kernel security team (who did not reach out to distributions). So the distributions are all scrambling now. Good lesson in how not to do disclosure.

Why wouldn't the kernel security team reach out to distributions?

Re: Copy Fail

#472

Post by tomxor »

dsr_ wrote: post #420
globular-toast wrote: post #350

Earlier quoted context omitted.

Is it built as a module in most distros?

It is built as a module in Debian. lsmod shows it is not loaded on any of the Trixie or Bookworm machines I have checked, Intel or AMD.

FYI it's dynamically loaded on demand, so lsmod will show it after you try run the exploit, or you can explicitly load it with:

  modprobe algif_aead
The following mitigation (from the article) does work for Debian 12 and 13, I've tested this:

  echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  rmmod algif_aead 2>/dev/null || true
First line blocks it from loading, second line is unloading it if it's already been loaded. You can test with the same "modprobe algif_aead".

Re: Copy Fail

#474

Post by wang_li »

stackghost wrote: post #217
wang_li wrote: post #133

Earlier quoted context omitted.

it's living in your page cache, not on your disk. flush the caches and it'll disappear.

Indeed. But it's easier to just kill a container or a k8s node and reprovision than to flush the caches

Should be able to just echo a 1 to /proc/sys/vm/drop_caches.

Re: Copy Fail

#475

Post by zackr »

42wim wrote: post #440

I've (well, mostly Claude did) created a module that unloads the active AF_ALG (builtin) module and mitigates the exploit without having to reboot. Tested on almalinux8/9 https://gist.github.com/42wim/2e3cc3c92333e4c2730541e6f0e038... YMMV

looking good to me so far, thank you!

Re: Copy Fail

#476

Post by zbentley »

wolttam wrote: post #453
ebiggers wrote: post #232

As 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…

I love this. I think everyone in software should be feeling a tinge of “we should trim the fat” right now - get rid of as much of the old and infrequently used/tested code as we can. Push users towards the better tested alternatives.

But but but … wE dOnT bREaK uSErsPaCe!

Re: Copy Fail

#477

Post by mobeigi »

Orygin wrote: post #405
vntok wrote: post #360

Earlier quoted context omitted.

Definitely comes over as salty. Naming major flaws has been a tradition for decades. Remember Heartbleed? It had a site and a logo :) Shellshock, Meltdown, Spectre as well. A few more: https://github.com/hannob/vulns This site though is pretty useful; first it serves as a central location to point people to with short links in chats/emails/whatever, then it has a quick visual explainer and a link to the detailed tech…

It used to be done for fame and visibility. Give a marketable name and a website, your exploit will be talked about and your name will shine in the industry. Now it's done by an LLM to sell more LLMs services. Disclosure is botched to have the most sensational title so more click more upsell.

I'm being very cynical here but who says that their tool or LLM discovered this. How do we know they didn't hire some expert security researchers to find it or bought it off the black market as a promotion stunt.

With that being said, I wouldn't mind if they made more sales on whatever they're advertising IF they followed the disclosure process well. A bad disclose immediately tells me I can't trust them because their moment in the light was more important that the safety of millions of boxes.

Re: Copy Fail

#478

Post by [deleted] »

strenholme wrote: post #318
buredoranna wrote: post #286

Earlier quoted context omitted.

Please don't rely on my judgement for this being safe for production, but after blacklisting the modules, the provided python exploit failed. Check if the following are modules grep CONFIG_CRYPTO_USER_API /boot/config-$(uname -r) If they are, you can try blacklisting them /etc/modprobe.d/blacklist-crypto-user-api.conf """ blacklist af_alg blacklist algif_hash blacklist algif_skcipher blacklist algif_rng blacklist alg…

I can’t comment on the ramifications, except to note that elsewhere in the thread this appears to not break anything (whether it makes userspace crypto a little less safe is academic, but that doesn’t matter if we have an easy local root shell), but I can verify the above fix does protect Ubuntu 24.04 from the exploit. Just reboot after applying this change.

[deleted]

Re: Copy Fail

#479

Post by tptacek »

DannyBee wrote: post #225

I love how it says "Standalone PoC. Python 3.10+ stdlib only (os, socket, zlib). Targets /usr/bin/su by default; pass another setuid binary as argv[1]." Except you can't pass another setuid binary as argv[1] because the AI writing this slop never added that feature to this python script. I can't get it to work on any distro i've tried.

The landing page is just bad. There's no way around it.

The bug is pretty great. I feel bad for the researchers who did the work.

Re: Copy Fail

#480

Post by handedness »

fsflover wrote: post #341

As usual, Qubes is not vulnerable, since by its design, any untrusted software runs in dedicated VMs with hardware virtualization. Meanwhile, recent Xen CVEs also do not affect Qubes, as usual, https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...

Why do you suppose Joanna Rutkowska made a point of calling Qubes OS "reasonably secure", rather than making claims like, "Qubes is not vulnerable" and "there is no attack vector"?
Post reply on HN