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

321–330 of 545 posts

Re: Copy Fail

#321

Post by ebiggers »

400thecat wrote: post #320
ebiggers wrote: post #290

Earlier quoted context omitted.

If iwd, or cryptsetup with certain non-default algorithms, isn't being used on the system, you should be fine. Not many programs use AF_ALG. It's possible there are others I'm not aware of, but it's quite rare. To be clear, general-purpose Linux distros generally can't disable these kconfig options yet, due to these cases. But there are many Linux systems that simply don't need this functionality. A good project for…

is CONFIG_CRYPTO_USER_API needed for hw acceleration for cryptsetup (dm-crypt) disk encryption ?

No, dm-crypt just calls the kernel's crypto code directly.

Re: Copy Fail

#322

Post by nromiun »

still_grokking wrote: post #260
staticassertion wrote: post #257

Earlier quoted context omitted.

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?

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.

Re: Copy Fail

#323

Post by nromiun »

I tried this exploit on Android and it looks like you need root in the first place to create an AF_ALG socket. I guess it is an SELinux policy to disable AF_ALG entirely.

Re: Copy Fail

#324

Post by KnuthIsGod »

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…

Removing this will make the friendly spooks at NSA very sad....

Re: Copy Fail

#325

Post by hnarn »

arcfour wrote: post #235

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

most distros backport fixes which does not increment that version number. i.e. they patch it, they do not ship a completely new kernel release.

Re: Copy Fail

#326

Post by n3rdr4g3 »

john_strinlai wrote: post #11
Lorin wrote: post #3

What is the rationale behind naming CVEs and individual domains? Marketing?

can you remember what CVE-2021-44228 is without looking it up? CVE-2014-6271? CVE-2017-5753? i bet if i told you their names, you would instantly know what vulns those are. its easier to talk about things with names. it hurts no one. it takes approximately no effort or time. CVEs are, for whatever reason, like the only thing on the planet that people seem to have a problem with when they receive a name. i am not sure…

For anyone else that was curious they're log4j, shellshock, and spectre

Re: Copy Fail

#327

Post by [deleted] »

Tuna-Fish wrote: post #88
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…

Yeah, by ubuntu's own guidelines linked on that page, this should be priority: high, but instead it's marked as medium.

[deleted]

Re: Copy Fail

#328

Post by tosti »

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 think it would be reasonable to deprecate af_alg in favor of a character device. It's more accessible that way. The downside is that the maintainers hate adding new ioctls. I think that's fair. But I don't think a "regular" device node would cover the functionality userland expects.

That said, elsewhere ITT it's pointed out there are only a few use cases so far.

Re: Copy Fail

#329

Post by ranger_danger »

WhyNotHugo wrote: post #242

> Any setuid-root binary readable by the user works. Interesting detail. On Alpine, `/usr/bin/su` is not readable by any user, so the PoC doesn't work. I suspect that the underlying issue can be exploited in other ways, but it makes me think that there's no reason for any suid binary to be world-readable.

Wouldn't executing it still put it in the page cache, just in a different place?

Re: Copy Fail

#330

Post by m-ueberall »

giis wrote: post #267

As soon as I read this >Shared dev boxes, shell-as-a-service, jump hosts, build servers — anywhere multiple users share a kernel. any user becomes root jumped out of bed and went straight into webminal.org servers as local user and ran the python code. It says permission denied on sock() call. Then I tested with local laptop with it: ``` $ uname -a Linux debian 6.12.43+deb12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.4…

I also tested this on an Ubuntu 24.04 (x86_64) host w/ GA kernel ("6.8.0-103-generic #103-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 10 13:34:59 UTC 2026 x86_64 GNU/Linux") and wasn't able to reproduce the "problem", although `canonical-livepatch` tells me that there are currently "no livepatches available".
Post reply on HN