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

281–290 of 545 posts

Re: Copy Fail

#281

Post by eqvinox »

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…

The primary benefit of AF_ALG is IMHO when it's combined with kernel keyrings, i.e. ALG_SET_KEY_BY_KEY_SERIAL.

To steal from the sibling post:

> * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters are handed to the kernel. The calling application now can reliably erase that information [...]

It's even more than this: you can do crypto ops in user space without ever even having the key to begin with.

[Ed.: that said, maybe AF_ALG should be locked behind some CAP_*]

[Ed.#2: that said^2, I'm putting this one on authencesn, not AF_ALG. It's the extended sequence number juggling that went poorly, not AF_ALG at large. I bet this might even blow up in some strange hardware scenarios, "network packet on PCIe memory" or something like that - I'm speculating, though.]

Re: Copy Fail

#282

Post by angry_octet »

eqvinox wrote: post #281
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…

The primary benefit of AF_ALG is IMHO when it's combined with kernel keyrings, i.e. ALG_SET_KEY_BY_KEY_SERIAL. To steal from the sibling post: > * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters…

Better implemented as another user space process than in the kernel.

Re: Copy Fail

#283

Post by dawnerd »

ryandrake wrote: post #240
jesse_dot_id wrote: post #190

Good thing nobody is silly enough to let fully autonomous AI agents run as regular users on these affected operating systems. That could be disastrous given a zero day prompt injection technique.

Good thing we haven't normalized installing things with curl | sh

Or npm being allowed to run arbitrary post install scripts

Re: Copy Fail

#284

Post by eqvinox »

angry_octet wrote: post #282
eqvinox wrote: post #281

Earlier quoted context omitted.

The primary benefit of AF_ALG is IMHO when it's combined with kernel keyrings, i.e. ALG_SET_KEY_BY_KEY_SERIAL. To steal from the sibling post: > * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters…

Better implemented as another user space process than in the kernel.

You can't access TPMs that way.

Re: Copy Fail

#285

Post by dezgeg »

comfydragon wrote: post #197
tremon wrote: post #191

Earlier quoted context omitted.

It's possible that the WSL kernel has that code compiled-in rather than as a loadable module. If they ship the kernel config somewhere, you could verify with zgrep CRYPTO_USER_API_AEAD /proc/config.gz /boot/config-* It should show =m if it's a loadable module, and =y if it's compiled in.

It's a loadable module: CONFIG_CRYPTO_USER_API_AEAD=m Using bpftrace to watch calls to module_request, openat, etc., it looks like when the kernel calls modprobe, it doesn't even look at the disable-algif.conf file: [module_request] pid=3648 comm=python name=algif-aead [umh_setup] pid=3648 comm=python path=/sbin/modprobe argv0=/sbin/modprobe argv1=-q argv2=-- argv3=algif-aead argv4= [openat] pid=3688 file=/etc/ld.so.…

In wsl, each distro you have runs in a container (with lot of permissions), you'd need to apply the modprobe change inside wsl "hypervisor" rootfs

Re: Copy Fail

#286

Post by buredoranna »

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 algif_aead

  install af_alg /bin/false
  install algif_hash /bin/false
  install algif_skcipher /bin/false
  install algif_rng /bin/false
  install algif_aead /bin/false
  """

  update-initramfs -u
Can anyone comment on the ramifications this?

Re: Copy Fail

#287

Post by sltkr »

commandersaki wrote: post #252

Tried this on my arch VPS which has a few users that hasn't been rebooted for 122 days. Got: OSError: [Errno 97] Address family not supported by protocol I guess AF_ALG is not part of the Arch Linux LTS kernel? Edit: Looks like on Arch you have to go out of your way to have this enabled. $ zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_…

On my Arch boxes the official exploit works, both with the LTS kernel (6.18.21-1-lts) and the mainline release (6.19.6-arch1-1).

Re: Copy Fail

#289

Post by acdha »

staticassertion wrote: post #245
acdha wrote: post #222

Earlier quoted context omitted.

That’s very optimistic. I’d bet there are an order of magnitude more people wondering how exposed they are than security researchers reading this.

https://duckduckgo.com/?q=LPE+security&ia=web wow

Sure, nobody’s saying it’s an inscrutable mystery but if your goal is to inform a wide audience it’s considered good form to expand all but the most common acronyms. It’ll even get you more internet points than petty smugness.

Re: Copy Fail

#290

Post by ebiggers »

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…

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 someone to work on would be to fix iwd and cryptsetup to always use userspace crypto, as they should.

Post reply on HN