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

311–320 of 545 posts

Re: Copy Fail

#311

Post by dnnddidiej »

tjbecker wrote: post #118
john_strinlai wrote: post #64

Earlier quoted context omitted.

> 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 they state that the write-up is forthcoming. presumably there is some additional steps or modifications that will be detailed in the 'part 2'. "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."

This is correct. The container escape exploit and writeup is not yet released.

Opus 4.7 it if you can't wait

Re: Copy Fail

#312

Post by ngomez »

ebiggers wrote: post #306
l1k wrote: post #300

Earlier quoted context omitted.

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…

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 unfortunate though since this is one thing I think Windows does decently well. The Windows crypto and TLS APIs do use a key isolation process by default (LSASS) and have a stable interface for other processes to use it [0]. I imagine systemd could implement something similar, but I also know that there are very strong opinions about adding more surface area to systemd.

[0] https://blackhat.com/docs/us-16/materials/us-16-Kambic-Cunni...

Re: Copy Fail

#313

Post by [deleted] »

pkoiralap wrote: post #212
m3nu wrote: post #203

I wasn't able to unload algif_aead on RHEL 9/10 because it's built in, rather than a module. So here the next-best thing I found: Disable AF_ALG via systemd. Needs drop-ins for all exposed services. Here an Ansible playbook that covers ssdh and user@, which are the main ones usually. https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...

I was coming up with the same intuition. However, it's like a whack-a-mole. What about cronjobs and slurmjobs and other services? Is there a way to do this directly on systemd so that all other processes inherit it rather than doing it on each one?

[deleted]

Re: Copy Fail

#314

Post by markhahn »

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.

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. yes, this is somewhat uncommon these days, when shell access is not the norm.

but consider the very common sort of shared hosting environment: they typically provide something like plesk to interface to shared machines with no particular isolation. can you (as a website owner or 0wner) convince wordpress/etc to drop and execute a script? yep.

Re: Copy Fail

#315

Post by anabis »

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…

Many things, such as ksmbd seems ill-advised when looked at from security. New AI driven exploits era will likely make projects more wary to adding functions.

Re: Copy Fail

#316

Post by l1k »

ebiggers wrote: post #306
l1k wrote: post #300

Earlier quoted context omitted.

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…

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 kernel's implementation of RSA isn't hardened against timing attacks

Cloudflare is using custom BoringSSL-based crypto code in the kernel:

https://lore.kernel.org/all/CALrw=nEyTeP=6QcdEvaeMLZEq_pYB9W...

Re: Copy Fail

#317

Post by stackghost »

staticassertion wrote: post #246
hackernudes wrote: post #226

Earlier quoted context omitted.

I've read many CVEs (somehow that acronym is ok... heh) but have never seen LPE despite being familiar with the concept.

That seems literally borderline impossible.

I could see it for someone who is only somewhat in tune with security work today.

Back in the day those of us breaking into shitty php sites didn't use LPE, we used "privesc", IIRC.

Re: Copy Fail

#318

Post by strenholme »

buredoranna wrote: post #286
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…

Please don't rely on my judgement for this being safe for production, but after blacklisting the modules, the provided python exploit failed. Check if the following are modules grep CONFIG_CRYPTO_USER_API /boot/config-$(uname -r) If they are, you can try blacklisting them /etc/modprobe.d/blacklist-crypto-user-api.conf """ blacklist af_alg blacklist algif_hash blacklist algif_skcipher blacklist algif_rng blacklist alg…

I can’t comment on the ramifications, except to note that elsewhere in the thread this appears to not break anything (whether it makes userspace crypto a little less safe is academic, but that doesn’t matter if we have an easy local root shell), but I can verify the above fix does protect Ubuntu 24.04 from the exploit.

Just reboot after applying this change.

Re: Copy Fail

#319

Post by TheDong »

dnnddidiej wrote: post #308
alpn wrote: post #234

Earlier quoted context omitted.

For anyone wondering: AF_ALG is a Linux socket interface that exposes the kernel’s crypto API via file descriptors, using normal read(2)/write(2) calls for hashing and encryption.

I wonder can the kernel just remove it and distros put on a compatiability layer.

It's already a configurable option in the kernel which can be fully disabled by distros if they wanted to provide their own compatibility layer, or just not ship any software that has a hard dependency on it.

Re: Copy Fail

#320

Post by 400thecat »

ebiggers wrote: post #290
buredoranna wrote: post #286

Earlier quoted context omitted.

Please don't rely on my judgement for this being safe for production, but after blacklisting the modules, the provided python exploit failed. Check if the following are modules grep CONFIG_CRYPTO_USER_API /boot/config-$(uname -r) If they are, you can try blacklisting them /etc/modprobe.d/blacklist-crypto-user-api.conf """ blacklist af_alg blacklist algif_hash blacklist algif_skcipher blacklist algif_rng blacklist alg…

If iwd, or cryptsetup with certain non-default algorithms, isn't being used on the system, you should be fine. Not many programs use AF_ALG. It's possible there are others I'm not aware of, but it's quite rare. To be clear, general-purpose Linux distros generally can't disable these kconfig options yet, due to these cases. But there are many Linux systems that simply don't need this functionality. A good project for…

is CONFIG_CRYPTO_USER_API needed for hw acceleration for cryptsetup (dm-crypt) disk encryption ?
Post reply on HN