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

391–400 of 545 posts

Re: Copy Fail

#391

Post by dontdoxxme »

RandomGerm4n wrote: post #380

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.

Re: Copy Fail

#392

Post by m3nu »

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…

What other kernel modules would you suggest disabling that aren't used usually?

Re: Copy Fail

#393

Post by lostmsu »

ngomez wrote: post #312
ebiggers wrote: post #306

Earlier quoted context omitted.

That can be done in userspace too -- different userspace processes have different address spaces too. The fact that the first link recommends using keyctl() for RSA private keys is also "interesting", given that the kernel's implementation of RSA isn't hardened against timing attacks (but userspace implementations of RSA typically are).

The CloudFlare blog discusses that idea when they talk about having an "agent process" to hold cryptographic material, but they list drawbacks like having to develop two processes, implement a well-defined interface, and enforce ACLs. I'm not convinced that "developing two processes" is a reason not to do it, since the kernel is effectively just the second process now, but everything else makes sense. It's unfortunat…

TBH LSASS is privileged enough to be a good target for exploits.

Re: Copy Fail

#394

Post by petcat »

ramon156 wrote: post #347
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.”

I dont really get why you'd - buy a domain - vibe code a page/artifact/whatever (which, given the quality of LLM wordings, only makes an argument less strong) - post it on HN with no further explanation in the title Why not write a detailed report? Even a tweet makes much more sense in my head than this. Even a logo?? Sorry if this comes over as salty, I guess I'm just not getting the thought process.

> I dont really get why you'd buy a domain [...] Even a tweet makes much more sense in my head than this

I think we should be celebrating people hosting their own content on their own website instead of just posting on some social media site.

Re: Copy Fail

#395

Post by ilaksh »

Does this affect my Hetzner VPSs running Ubuntu probably? Or Nebius H200 VMs?

They are probably Ubuntu 24 but don't remember.

Re: Copy Fail

#396

Post by rcxdude »

CGamesPlay wrote: post #297
rcxdude wrote: post #60

Earlier quoted context omitted.

If you can get to real UID 0 from a rootless container, you can escape it, but you do need to take extra steps. Same with it working on Alpine: the underlying vulnerability probably still exists, but the script might need some adjusting. It's a PoC, not a full exploit for every situation.

It's worth pointing out that you cannot, definitionally, get "real UID 0" in a "rootless" container, because then it wouldn't be a rootless container. This is relevant because this exploit doesn't claim to be able to bypass user namespaces, and that getting "real UID 0" would be a different exploit.

The underlying exploit allows writing arbitrary values to the page cache, independent of any namespacing, so it should be assumed to allow container escapes even if the given PoC code doesn't do that.

Re: Copy Fail

#397

Post by tyilo »

rkeene2 wrote: post #172
hashstring wrote: post #167

Earlier quoted context omitted.

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.

Fair enough -- a simpler change might be to poison /etc/passwd and call `su` to a user that has uid 0, since that requires no shell code nor a readable binary, and this seems to have worked in a slightly modified POC: f=g.open("/etc/passwd",0); e="rkeene:x:0:0:System administrator:/root:/run/current-system/sw/bin/bash\n".encode() ... g.system("/run/wrappers/bin/su - rkeene")

There is a PoC that does exactly that here: https://github.com/tgies/copy-fail-c

Re: Copy Fail

#398

Post by otherme123 »

stingraycharles wrote: post #356
ramon156 wrote: post #347

Earlier quoted context omitted.

I dont really get why you'd - buy a domain - vibe code a page/artifact/whatever (which, given the quality of LLM wordings, only makes an argument less strong) - post it on HN with no further explanation in the title Why not write a detailed report? Even a tweet makes much more sense in my head than this. Even a logo?? Sorry if this comes over as salty, I guess I'm just not getting the thought process.

I think they’re using it to promote their product, Xint Code, which was used to discover it. That’s the way I read it anyway.

I hope they sell a lot of Xint Code licenses, so they don't have to sell their findings.

Re: Copy Fail

#399

Post by a96 »

globular-toast wrote: post #351
arcfour wrote: post #233

Earlier quoted context omitted.

LPE is a very well-known acronym within the security community, it's not purely academic or obscure or anything. I agree that it would be a good idea to define it explicitly when writing for a broader audience, but I don't think it's particularly egregious that they didn't. It's certainly something I could see myself forgetting. Then again, the whole writeup appears to be AI-generated, so...

Sure, but the target audience of copy.fail is surely not the security community but regular sysadmins who probably don't otherwise follow as closely.

I would absolutely expect a sysadmin in particular to know and understand the term and acronym.

Re: Copy Fail

#400

Post by nh2 »

Sophira wrote: post #381
archon810 wrote: post #348

Earlier quoted context omitted.

modprobe algif_aead modprobe: FATAL: Module algif_aead not found in directory /lib/modules/6.14.3-x86_64-linode168 Yet this kernel is vulnerable.

That would suggest that CRYPTO_USER_API_AEAD=y in your kernel config. You can disable it in that case by setting that to "n", recompiling your kernel, and putting the new kernel in place.

Indeed, no modprobe.d will help when the feature is compiled into the kernel ("=y") instead of compiled into a runtime-loadable module.
Post reply on HN