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

451–460 of 545 posts

Re: Copy Fail

#451

Post by TZubiri »

a96 wrote: post #404
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…

Beware that running this kind of thing even as a test on a host you don't own may well be a criminal offense!

Everything MAY be a criminal offense. Whether it has any merit is another matter.

If I were accused of anything criminal for running this in a host, my defense would be that I was checking the safety of a service I was being offered. If the service was vulnerable, I would counterclaim, if you are on the defense you are already losing.

Re: Copy Fail

#452

Post by parliament32 »

TZubiri wrote: post #448
parliament32 wrote: post #426

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.

They have a setting for that? That's crazy, feels like prompting "make no mistakes" to the llm. If it works, when would you want it turned on? Why isn't false the default

Because it would break all setuid binaries? Same reason the Linux kernel doesn't set no_new_privs (https://docs.kernel.org/userspace-api/no_new_privs.html) by default.

As an operator you are responsible for configuring your environment correctly. I would recommend starting here: https://kubernetes.io/docs/concepts/security/

Re: Copy Fail

#453

Post by wolttam »

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.

Re: Copy Fail

#454

Post by jcul »

jeffwass wrote: post #336

This submission is currently the main HN submission. As of now the submission title is simply “Copy Fail”. Given the severity of the exploit, can we edit the Title to add some context that it’s a major Linux vulnerability? Eg the other submissions say this : “Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.”

Yes, strongly agree.

This is HUGE news, I would have skimmed over "Copy Fail".

The blog post might be a better place to link to also, it has more details on the exploit.

https://xint.io/blog/copy-fail-linux-distributions

There are also some good threads on which distros are vulnerable and mitigations on the github page.

https://github.com/theori-io/copy-fail-CVE-2026-31431/issues

Re: Copy Fail

#455

Post by parliament32 »

XorNot wrote: post #377
dwedge wrote: post #366

Earlier quoted context omitted.

Only for your user, and it means a keylogger on the system if it gets rooted can't pull your password to try on other machines. Personally I always either login as root or use passwordless sudo.

Yubikeys are also surprisingly annoying when setup for the as well. A working developer just needs sudo a lot. Realistically a "sudo button" would be handy, on the keyboard, with a display to show a confirmation pin for the request (probably also needs a deny button so you can try and identify weird ones).

Sounds like a good use case for that new Copilot button you see on newer keyboards.

Re: Copy Fail

#456

Post by fsflover »

kuhsaft wrote: post #445
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...

You know that Xen is just a hypervisor right? Dom0 (the admin Qube) is running the Linux kernel and is vulnerable like any other Linux system. DomU (App Qubes) also run the Linux kernel and are just as vulnerable. You can check your DomU kernels using this guide: https://doc.qubes-os.org/en/latest/user/advanced-topics/mana... If your Dom0 or DomU is running kernel https://github.com/QubesOS/qubes-linux-kernel/pull/12…

> Dom0 (the admin Qube) is running the Linux kernel and is vulnerable

Yes, it is vulnerable, except there is no attack vector, as you don't run any software there: https://doc.qubes-os.org/en/r4.3/user/downloading-installing...

> DomU (App Qubes) also run the Linux kernel and are just as vulnerable.

I think you misinterpret the Qubes approach to security. If you do everything in one VM, you get no protection from the virtualization. Moreover, there is no sudo password by design: https://doc.qubes-os.org/en/r4.3/user/security-in-qubes/vm-s... This is not how to use Qubes.

You need to compartmentalize your workflows. It doesn't matter if my disposable VM is compromised. My secrets are in another, offline VM, where I never run anything. There is no way to use the discussed vulnerability, if one uses Qubes according to docs. See examples here: https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to...

Re: Copy Fail

#457

Post by TZubiri »

parliament32 wrote: post #452
TZubiri wrote: post #448

Earlier quoted context omitted.

They have a setting for that? That's crazy, feels like prompting "make no mistakes" to the llm. If it works, when would you want it turned on? Why isn't false the default

Because it would break all setuid binaries? Same reason the Linux kernel doesn't set no_new_privs ( https://docs.kernel.org/userspace-api/no_new_privs.html ) by default. As an operator you are responsible for configuring your environment correctly. I would recommend starting here: https://kubernetes.io/docs/concepts/security/

https://kubernetes.io/docs/concepts/security/pod-security-st...

Relevant section

Re: Copy Fail

#458

Post by danparsonson »

TZubiri wrote: post #451
a96 wrote: post #404

Earlier quoted context omitted.

Beware that running this kind of thing even as a test on a host you don't own may well be a criminal offense!

Everything MAY be a criminal offense. Whether it has any merit is another matter. If I were accused of anything criminal for running this in a host, my defense would be that I was checking the safety of a service I was being offered. If the service was vulnerable, I would counterclaim, if you are on the defense you are already losing.

You understand there's a difference between how the law is, and how you think it should be, right? Only one of those things will actually help you in court.

Re: Copy Fail

#459

Post by stratos123 »

TZubiri wrote: post #448
parliament32 wrote: post #426

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.

They have a setting for that? That's crazy, feels like prompting "make no mistakes" to the llm. If it works, when would you want it turned on? Why isn't false the default

It's equivalent to setting no_new_privs on the container process, so it'd mean you have to grant a privelege to the container process if you want any children to have access to it. It sure sounds funny in a CVE context, though.

Re: Copy Fail

#460

Post by dataflow »

RandomGerm4n wrote: post #431
dontdoxxme wrote: post #391

Earlier quoted context omitted.

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

Yeah. The whole Linux security model seems like it was designed centuries ago. Your permissions are supposed to derive from the authority granted to you at the time of your invocation, and from those with the existing authority to grant/delegate them... not from your lineage, name, possessions, or status at birth. I find it kind of funny that generations of *nix engineers appear to have perpetually struggled with this concept. For all the hate it gets, Windows got this part fundamentally right.
Post reply on HN