← Back to context

Comment by buredoranna

15 hours ago

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?

9 comments

buredoranna

Reply
ebiggers  15 hours ago

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.

strenholme  13 hours ago

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.

globular-toast  10 hours ago

Is it built as a module in most distros?

  • dsr_  5 hours ago

    It is built as a module in Debian.

    lsmod shows it is not loaded on any of the Trixie or Bookworm machines I have checked, Intel or AMD.

    • tomxor  2 hours ago

      FYI it's dynamically loaded on demand, so lsmod will show it after you try run the exploit, or you can explicitly load it with:

        modprobe algif_aead

      The following mitigation (from the article) does work for Debian 12 and 13, I've tested this:

        echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  rmmod algif_aead 2>/dev/null || true

      First line blocks it from loading, second line is unloading it if it's already been loaded. You can test with the same "modprobe algif_aead".