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

161–170 of 545 posts

Re: Copy Fail

#161

Post by ranger_danger »

marshray wrote: post #151
john_strinlai wrote: post #128

Earlier quoted context omitted.

in this specific case, they offer an alternative mitigation if your chosen distro has not updated yet: For immediate mitigation, block AF_ALG socket creation via seccomp or blacklist the algif_aead module: echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf rmmod algif_aead 2>/dev/null

Thanks! I'd do 'umask 133' in front of the echo out of paranoia. Out of curiosity, was the asterisk after '2>/dev/null' intentional? I had not seen that idiom before.

And I would do chattr +i disable-algif.conf

Re: Copy Fail

#162

Post by tosti »

themafia wrote: post #26

> If your kernel was built between 2017 and the patch This is why I compile my own kernel. I disable things I don't use. If it's not present it can't hurt you. > block AF_ALG socket creation via seccomp regardless of patch state. Likewise I use seccomp to only allow syscalls that are necessary. Everything else is disabled. In the programs I have that need to connect to a backend socket, that is done, and then socket…

Any pointers on how to set that up? Like, run all the things through strace, cut the first field, sort, uniq, run through some template and something somesuch what how?

Re: Copy Fail

#163

Post by rkeene2 »

I couldn't get the POC to work with my version of Python so I had ChatGPT convert it to C [0] and was able to verify my Slackware system does not appear to be affected, but my NixOS system would be if I had any world-readable suid binaries (which I had to make one to test it).

[0] https://rkeene.org/viewer/tmp/copy_fail_exp.c.htm

Re: Copy Fail

#164

Post by comfydragon »

oskarkk wrote: post #81
1p09gj20g8h wrote: post #76

Earlier quoted context omitted.

Where are you seeing the disabling algif_aead mitigation?

In TFA: https://copy.fail/#mitigation > Before you can patch: disable the algif_aead module. > echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf > rmmod algif_aead 2>/dev/null || true Edit: and I can confirm that on my system with kernel 6.19.8 the above fixes the exploit.

Weirdly, the mitigation does not seem to work under WSL2 (at least in Ubuntu 24.04).

    Linux wsl2 6.6.87.2-microsoft-standard-WSL2 ...
`modprobe algif_aead` errors out, but if I run the POC, it succeeds.

Outside of WSL2, the mitigation does appear to work though.

Re: Copy Fail

#165

Post by ranger_danger »

kro wrote: post #16
Ekaros wrote: post #13

So this could be usable in lot of places with Python and Linux running? Not that I have too many Linux devices around. Still, might be handy sometimes on personal devices.

This can likely be shipped as binary code without dependencies like python, as the bug is in the kernel.

C version here: https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb0...

Re: Copy Fail

#166

Post by rkeene2 »

zerocrates wrote: post #146
rkeene2 wrote: post #106

Interestingly it fails for me because my `su` isn't world-readable: $ stat /bin/su File: /bin/su Size: 59552 Blocks: 118 IO Block: 59904 regular file Device: 0,52 Inode: 796854 Links: 1 Access: (4711/-rws--x--x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2023-09-18 13:23:03.117105665 -0500 Modify: 2021-02-13 05:15:56.000000000 -0600 Change: 2023-09-18 13:23:03.119105665 -0500 Birth: 2023-09-18 13:23:03.117105665 -0500 I…

It being readable is the default configuration most places, after all the purpose is to call it from a non-privileged user. But I could see it being made non-readable since its use is discouraged nowadays... though then I'd expect sudo to be readable as an alternative.

My `sudo` is also not readable. Files/directories don't need to be readable to be executed. I can still use `su` and `sudo`.

Re: Copy Fail

#167

Post by hashstring »

rkeene2 wrote: post #111
rkeene2 wrote: post #106

Interestingly it fails for me because my `su` isn't world-readable: $ stat /bin/su File: /bin/su Size: 59552 Blocks: 118 IO Block: 59904 regular file Device: 0,52 Inode: 796854 Links: 1 Access: (4711/-rws--x--x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2023-09-18 13:23:03.117105665 -0500 Modify: 2021-02-13 05:15:56.000000000 -0600 Change: 2023-09-18 13:23:03.119105665 -0500 Birth: 2023-09-18 13:23:03.117105665 -0500 I…

A workaround might be to make all setuid/setgid files non-world-readable because then they cannot be opened at all, and thus there is no setuid file to replace the contents of.

Eh, if you can pollute page caches this won’t safe you.

Think modifying shared libraries, ld preload, cron, I guess on some systems /etc/passwd even.

There are a lot of files readable that should definitely not be writable.

Re: Copy Fail

#169

Post by mghackerlady »

MarleTangible wrote: post #89
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…

Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority. https://ubuntu.com/security/cves/about#priority > Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.

it's not like this couldn't be chained with some other exploit to get remote access to get remote root access which seems like a bit of an issue

Re: Copy Fail

#170

Post by Twirrim »

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…

> They also claim their script "roots every Linux distribution shipped since 2017.", but only tested four; and it doesn't work on Alpine

They've done themselves no favours at all with their write up.

It does seem legitimate (I was able to use the PoC on a 24.04 instance), and seems like it should be a big deal, but the actual number of affected distributions seems way lower, and not even remotely as per their claim every distribution since 2017.

For example with Ubuntu, if I'm reading it right there's some impact in 16.04 (EOL), but then at least as per their analysis, only the vendor specific 6.17 kernels they ship that have it (e.g. linux-gcp, linux-oracle-6.7 etc.). That's a relatively new kernel version they started shipping recently, after it was released upstream last September.

Post reply on HN