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

241–250 of 545 posts

Re: Copy Fail

#241

Post by byron3256 »

m3nu wrote: post #203

I wasn't able to unload algif_aead on RHEL 9/10 because it's built in, rather than a module. So here the next-best thing I found: Disable AF_ALG via systemd. Needs drop-ins for all exposed services. Here an Ansible playbook that covers ssdh and user@, which are the main ones usually. https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...

How about blacklisting algif_aead initialization function on RHEL 9/10? I added "initcall_blacklist=algif_aead_init" to the kernel boot options and rebooted. The exploit is not working anymore.

Re: Copy Fail

#242

Post by WhyNotHugo »

> 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.

Re: Copy Fail

#243

Post by staticassertion »

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…

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).

Re: Copy Fail

#244

Post by userbinator »

tardedmeme wrote: post #210
akdev1l wrote: post #122

Earlier quoted context omitted.

No, Android doesn’t have suid binaries to exploit like in the PoC

The vulnerability can also be used on any binary that is already running as root and you can open for reading. So yes, any android app can now escalate to root if android has the vulnerable module.

Unfortunately another comment thread here says that it doesn't.

Re: Copy Fail

#245

Post by staticassertion »

acdha wrote: post #222
boston_clone wrote: post #181

Earlier quoted context omitted.

it’s a CVE write up; the audience for these knows what an LPE is.

That’s very optimistic. I’d bet there are an order of magnitude more people wondering how exposed they are than security researchers reading this.

https://duckduckgo.com/?q=LPE+security&ia=web

wow

Re: Copy Fail

#246

Post by staticassertion »

hackernudes wrote: post #226
boston_clone wrote: post #181

Earlier quoted context omitted.

it’s a CVE write up; the audience for these knows what an LPE is.

I've read many CVEs (somehow that acronym is ok... heh) but have never seen LPE despite being familiar with the concept.

That seems literally borderline impossible.

Re: Copy Fail

#247

Post by x4132 »

progval wrote: post #51

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

there is a PoC floating around for Alpine.

Re: Copy Fail

#248

Post by x4132 »

microtherion wrote: post #101
progval wrote: post #51

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

It also doesn't work on Raspberry Pi, though presumably it could easily be made to; it does replace the su binary, but the replacement is not executable.

this is because the `su` binary is replaced with x86 shellcode, replace it with aarch64 and it will work just the same.

Re: Copy Fail

#249

Post by x4132 »

marshray wrote: post #125
john_strinlai wrote: post #65

Earlier quoted context omitted.

Disclosure timeline 2026-03-23Reported to Linux kernel security team 2026-03-24Initial acknowledgment 2026-03-25Patches proposed and reviewed 2026-04-01Patch committed to mainline 2026-04-22CVE-2026-31431 assigned 2026-04-29Public disclosure (https://copy.fail/) kernel 6.19.14-arch1-1, the kernel in question from the parent comment, has been patched.

The lesson here being... compile your own kernel from git sources every few days? Give up entirely on non-virtualized container security? This is not sarcasm. I'd finally given in and started learning about docker/podman-style OCI containerization last week.

are you sure containerization would be more secure? this is also a rootless podman escape. the lesson here is to not give random people shell access to your systems.

Re: Copy Fail

#250

Post by sidewndr46 »

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…

any idea what software this will break once I turn this kernel configuration off?
Post reply on HN