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

521–530 of 545 posts

Re: Copy Fail

#521

Post by globular-toast »

a96 wrote: post #399
globular-toast wrote: post #351

Earlier quoted context omitted.

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.

Well I would expect a sysadmin to have already been following the kernel mailing lists and not even need to look at copy.fail.

In fact, why do people even write stuff down? Everyone should just know everything.

Re: Copy Fail

#522

Post by amluto »

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…

IIRC some versions of cryptsetup require access to these APIs.

It doesn’t help that the historically dominant userspace implementation of most of this stuff was OpenSSL, which is also terrible.

Re: Copy Fail

#523

Post by amluto »

asveikau wrote: post #305
buckle8017 wrote: post #276

Earlier quoted context omitted.

You should take note that this is written by the person that wrote the bad patch. So grain of salt.

I feel like it should be possible to fulfill these advantages with a minimal, not very complex API. I.e. the grandparent's comment about IPsec implementation details doesn't make the cut, but a hardware accelerated cipher implementation does.

A hardware accelerated DMA-capable cipher implementation is an odd thing, and it’s generally not useful on its own. You might want to set up a whole chain of operations (encrypt, checksum, send to network, for example), but I’ve never encountered a case where you actually want to ask an accelerator to asynchronously encrypt application data and return the encrypted data to the application.

Re: Copy Fail

#524

Post by sharts »

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…

If it should not exist what’s the rationale for keeping it instead of removing it?

Re: Copy Fail

#525

Post by neuroelectron »

p_l wrote: post #344
still_grokking wrote: post #253

Earlier quoted context omitted.

As I did not know what AF_ALG is in the first place I've searched for it and found this here: https://www.chronox.de/libkcapi/html/ch01s02.html It states the following: > There are several reasons for AF_ALG: > * The first and most important item is the access to hardware accelerators and hardware devices whose technical interface can only be accessed from the kernel mode / supervisor state of the processor. Such sup…

AF_ALG if I remember correctly predates userspace-accessible crypto acceleration and was way more important back when it meant you had actual need for "SSL accelerator" cards in servers, among other things

Yes, I remember that time, it was back when I wasn't allowed to know anything about what servers were doing other than to look it up in the internal leak, which was never maintained

Re: Copy Fail

#526

Post by kuhsaft »

fsflover wrote: post #519
kuhsaft wrote: post #481

Earlier quoted context omitted.

So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable. > https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20... Looking at just that small list, they mark some vulnerabilities as not vulnerable because it's "In-VM attack only". That's disingenuous. > There is no way to use the…

> So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable. On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there. On the other hand, yes, any security does rely on you not doing something stupid like "curl | sudo bash". >…

> On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there.

And I'm fine with that. I think, the Qubes OS notices should use that terminology as well. Though, some of the vulnerabilities are exploitable, if you don't follow the Qubes OS guides to the T.

Re: Copy Fail

#527

Post by sjagoe »

senectus1 wrote: post #506
nh2 wrote: post #92

Earlier quoted context omitted.

On a git repo that has as remotes https://github.com/torvalds/linux.git https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git as remotes: running a search for commit a664bf3d603d's commit message: git log --all --grep 'crypto: algif_aead - Revert to operating out-of-place' '--format=%H' | xargs -I '{}' git tag --contains '{}' | sort -u outputs these tags as having the fix: v6.18.22 v6.18.23 v6.18.24 v6.18.…

Just curious.. do they list all those kernel version because there is regression in versions after 6.18.22 ? ie does v 6.19.0 have the flaw in it?

No, it was fixed initially in 7.0, and the patch then applied to the 6.18 and 6.19 branches, fixing the existing bug in versions 6.18.22 and 6.19.12. The bug exists in 6.19.0 to 6.19.11, but not as a regression - those were all released before the bug was fixed.

Re: Copy Fail

#529

Post by neuroelectron »

neuroelectron wrote: post #525
p_l wrote: post #344

Earlier quoted context omitted.

AF_ALG if I remember correctly predates userspace-accessible crypto acceleration and was way more important back when it meant you had actual need for "SSL accelerator" cards in servers, among other things

Yes, I remember that time, it was back when I wasn't allowed to know anything about what servers were doing other than to look it up in the internal leak, which was never maintained

*intenral wiki

Re: Copy Fail

#530

Post by PunchyHamster »

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…

over 500 servers with very varied workload i manage didn't had this module loaded so my guess is "near zero"

also only algif_aead is vulnerable

Post reply on HN