6 ms·
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 foll
by buredoranna 5mo 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?
- ebiggers 5mo agoIf 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 5mo agoI 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.
- deleted 5mo ago[deleted]
- Milpotel 5mo agoOr zgrep CONFIG_CRYPTO_USER_API /proc/config.gz
- globular-toast 5mo agoIs it built as a module in most distros?
- dsr_ 5mo agoIt 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 5mo agoFYI 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".
- globular-toast 5mo agoIt was loaded on my Ubuntu system so I wonder what used it.
- dundarious 5mo agoThe point of noting whether it is loaded on their machine or not, is presumably to indicate that it is not normally loaded (for them), so disabling it to block the exploit should have no impact (for them).
- alexdevphp 5mo agoAs I understands any program code can use that socket to write to page cache memory and modify any main program. Even php code can be written for that. So it is serious problem if there is other security hole on web server.
- PunchyHamster 5mo agoover 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
- deleted 5mo ago[deleted]