Live data from Hacker News

Copy Fail

copy.fail

431–440 of 545 posts

Re: Copy Fail

#431

That is why we should get rid of setuid binaries. GrapheneOS does not use them and was therefore not affected. On the desktop there is also a project called Secureblue based on Fedora Atomic that is moving in a similar direction and has already eliminated a large number though not all setuid binaries. As an alternative to sudo, su, and pkexec there is for example run0, which is available in distributions using system…

No, it is not affected by the exploit as presented. This is a page cache write, so writing to a binary that root will run later can work too. This isn’t a reason to push an agenda that dislikes setuid binaries.

That would only work if the user had access to a binary that they wanted to run as root. Ideally this shouldn’t happen at all for most users. There is almost never a legitimate reason to run any program as root unless for example it is a service that absolutely requires it. In Fedora based distributions SELinux also prevents systemd from running any binaries or scripts that the user has access to as root. Removing setuid binaries and strictly limiting features like user namespaces through SELinux would make Linux significantly more secure. It’s absolutely ridiculous that even an outdated Android smartphone is more secure than the average Linux distribution these days.

Re: Copy Fail

#432

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…

The upstream stable kernels (6.12.85, etc.) are out now with the fixes.

Re: Copy Fail

#433
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…

Could be worse (we'll see) as this could be a wild ride along with react2shell or some of the compromised packages as of late.

Re: Copy Fail

#434

Note that in kubernetes, setting `allowPrivilegeEscalation` to false (which you should be doing already, it's in the Pod Security Standards Restricted profile) mitigates this.

according to this reddit post https://www.reddit.com/r/kubernetes/comments/1szn6p1/comment...?

> the primary mitigation is still patching the node kernel; user namespaces are blast-radius reduction, not a complete mitigation for this path

Re: Copy Fail

#435

Is there a readable version of the exploit readily available by any chance? Gotta admit that I failed binary-zip-interpretation-with-naked-eye class twice

Go version came in handy https://github.com/badsectorlabs/copyfail-go especially for systems without the very latest python (os.slice)

Slightly more readable Python version at https://gist.github.com/grenkoca/b82281a4706e936072979acf54b...

Re: Copy Fail

#436
post #425
post #376

Earlier quoted context omitted.

Isn't the better argument to ask whether there'd be benefit if all those things did? A lack of adoption isn't apriori a good argument against an interface, and serious bugs can happen anywhere. My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers…

> My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers were invented. There’s a valid argument here but I think that’d devolve into the DNSSec trap without both a very well-designed API and a stable way to ship updates for older kernels. If peopl…

Which does sort of loop around to the issue of Linux not having a stable ABI as a feature I suppose which would be one way to implement it with long term compatibility on kernel modules.

But the Chrome example also highlights the problem: Chrome might ship it, but vanishingly little software is ever going to upgrade and we've got an explosion of statically linked languages now.

Re: Copy Fail

#437

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, it was also staged for release on the affected kernel branches a while ago, but almost all still had the window open and only tonight got the merged across all maintained kernel versions.

It's not good... and surely not "responsible/planned" disclosure.

Re: Copy Fail

#438

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.

I mean, most Kernel version literally got the patch 2026.04.30, so just today.

Re: Copy Fail

#439
post #352

Earlier quoted context omitted.

hmm have i missed anything?

Any program on your computer can just run "sudo" to escalate itself.

The problem is not the passwordless sudo but running untrusted programs on your computer under your user. They don’t need sudo to steal your SSH keys or inject malicious code in your .bashrc.
Post reply on HN