6 ms·

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 ke

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. The kernel's cryptography code is just for in-kernel users (for example, dm-crypt). The algorithm being used in this exploit, "authencesn", is even an IPsec implementation detail, which never should have been exposed to userspace as a general-purpose en/decryption API. If you're in charge of the configuration for a Linux kernel, I strongly recommend disabling all CONFIG_CRYPTO_USER_API_* kconfig options. This would have made this bug, and also every past and future AF_ALG bug, unexploitable. In the unlikely event that you find that it breaks any userspace programs on your system, please help migrate them to userspace crypto code! For some it's already been done. But in general, AF_ALG has actually never been used much in the first place, other than in exploits. I don't think there's much other option. This sort of userspace API might have been sort of okay many years ago. But it just doesn't stand up in a world with syzbot, LLM-assisted bug discovery, etc.

dev_l1x_be 5mo ago
Why is this available in the kernel on a box that does not use ipsec? should this be compile time enabled module instead than a generic solution?
- ButlerianJihad 5mo ago
  The design philosophy of mainstream Linux distros is not like OpenBSD. Linux distros go to market as maximally capable, maximally interoperable, and maximally available for whatever the users want to do. So there is a lot of "shovelware" that is unnecessarily installed with your base system. A lot of services are enabled that you don't need. A lot of kernel modules are loaded or ready to spring into action as soon as you connect hardware that the kernel recognizes. All this maximizing also increases the system's attack surface, whether local or over the network. Your resources, time and effort increase, to update the system and maintain all those packages. The TCO is high. With OpenBSD, the base system is hardened and the code is audited with security in mind. They only install or enable essential functions. So it's up to the user to dig in, customize it, and add in features that are needed. The good news is that you can do some after-market hardening. Uninstall software that you're not using, and disable non-essential services. Tune your kernel for special-purpose, or general-purpose, but not every-purpose. There are now special distros for containers and VMs with minimal system builds. They are designed to be as small and lightweight as possible. That is a good start in the right direction.
  - dev_l1x_be 5mo ago
    Thanks for the explanation. I am wondering if it is possible or does it make sense to have a modular linux that does not have these attack surfaces enabled by default. Alpine is my default solution for most Linux use cases (except when I need GPU support).
    - tosti 5mo ago
      Not "by default", but still Gentoo. My USE= is several lines worth of -this -that -all-the-things. I got rid of wayland, pipewire, pulseaudio, avahi and a shitload of other stuff I don't need. PulseAudio applications can still produce (but not record) audio through apulse and my handcrafted asoundrc
sidewndr46 5mo ago
any idea what software this will break once I turn this kernel configuration off?
- deleted 5mo ago
  [deleted]
- ebiggers 5mo ago
  iwd is the main culprit (for systems that use it instead of wpa_supplicant). I think cryptsetup / LUKS also requires it with some non-default options. With the default options, it works fine with the kconfigs disabled. There's not much else, as far as I know. Normally programs just use a userspace library instead, such as OpenSSL.
alpn 5mo ago
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.
- dnnddidiej 5mo ago
  I wonder can the kernel just remove it and distros put on a compatiability layer.
  - TheDong 5mo ago
    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.
    - adrian_b 5mo ago
      I always use only custom compiled kernels on my computers, where I enable only the configuration options that I really need. So the options related to AF_ALG have always been disabled, because I have not encountered an application that needs them, among those that I use. Unfortunately the Linux distributions must enable in their default configuration most options, because they cannot predict what their users will need.
still_grokking 5mo ago
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 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 support cannot be used from user space except through AF_ALG. > * 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 from its memory and just use the cipher handle to perform the cryptographic operations. If the application is cracked an attacker cannot obtain the key material. > * On memory constrained systems like embedded systems, the additional memory footprint of a user space cryptographic library may be too much. As the kernel requires the kernel crypto API to be present, reusing existing code should reduce the memory footprint. I can't judge whether this is a good justification, but there is one.
- buckle8017 5mo ago
  You should take note that this is written by the person that wrote the bad patch. So grain of salt.
  - still_grokking 5mo ago
    I've said I'm not sure about the validity of that reasoning. I've liked it nevertheless for context, as augmentation to parent's post.
  - asveikau 5mo ago
    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.
Fr0styMatt88 5mo ago
How did it get in? Isn’t Linus known for being rightfully fussy about what makes it into the kernel? Would be an interesting story.
- kasabali 5mo ago
  Linus has had been fussy about maybe like 5% of the things because even then he couldn't keep up with the sheer volume. Nowadays it's more like 1‰
eqvinox 5mo ago
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.]
- angry_octet 5mo ago
  Better implemented as another user space process than in the kernel.
  - eqvinox 5mo ago
    You can't access TPMs that way.
    - wetpaws 5mo ago
      [dead]
    - angry_octet 5mo ago
      Most of the Linux kernel crypto is not touching the TPM. If there is a TPM task, only that code should be in kernel, and it should be accessed from user space by a process with the appropriate token.
      - eqvinox 5mo ago
        Yes, AF_ALG is exposing too many things, like authencesn, which has zero reason for being userspace accessible. It's a crypto mode specific to IPsec. However, > it should be accessed from user space by a process with the appropriate token. That is AF_ALG. The operations it offers are what you need for full coverage. The issues with it are two: - usage specific crypto in the kernel implements the same interfaces, and it doesn't have a filter for that, as mentioned above. It's not offering too many operations, it's offering too many algorithms. - it's trying to be fast. I guess people also want to use crypto accelerators through it. (Which is kinda related to TPMs, there is accelerator hardware with built-in protected key storage...) The CVE we're looking at here is in the intersection of both of these.
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 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.
  - 400thecat 5mo ago
    is CONFIG_CRYPTO_USER_API needed for hw acceleration for cryptsetup (dm-crypt) disk encryption ?
    - ebiggers 5mo ago
      No, dm-crypt just calls the kernel's crypto code directly.
- strenholme 5mo 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.
l1k 5mo ago
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-service-and-why-you-should-use-it-in-your-next-application/ https://blog.cloudflare.com/the-linux-kernel-key-retention-s... https://www.youtube.com/watch?v=7djRRjxaCKk https://www.youtube.com/watch?v=7djRRjxaCKk https://www.youtube.com/watch?v=lvZaDE578yc 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 crypto/asymmetric_keys/ in the kernel and the author/presenter in the first two links is another co-maintainer.
- ebiggers 5mo ago
  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).
  - ngomez 5mo ago
    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-Cunning-With-CNG-Soliciting-Secrets-From-SChannel.pdf https://blackhat.com/docs/us-16/materials/us-16-Kambic-Cunni...
    - lostmsu 5mo ago
anabis 5mo ago
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.
KnuthIsGod 5mo ago
Removing this will make the friendly spooks at NSA very sad....
- tosti 5mo ago
  No, it'd make me sad. If they're lurking in there and we can do without, I'm happy to always have my own .config If this gets removed, they'll creep in somewhere we can't find them for a while.
tosti 5mo ago
I think it would be reasonable to deprecate af_alg in favor of a character device. It's more accessible that way. The downside is that the maintainers hate adding new ioctls. I think that's fair. But I don't think a "regular" device node would cover the functionality userland expects. That said, elsewhere ITT it's pointed out there are only a few use cases so far.
SeriousM 5mo ago
I was completely unaware of https://syzbot.org https://syzbot.org, thanks for sharing! > syzbot system continuously fuzzes main Linux kernel branches and automatically reports found bugs to kernel mailing lists. syzbot dashboard shows current statuses of bugs. All syzbot-reported bugs are also CCed to syzkaller-bugs mailing list. Direct all questions to syzkaller@googlegroups.com.
400thecat 5mo ago
can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum
m3nu 5mo ago
What other kernel modules would you suggest disabling that aren't used usually?
WhyNotHugo 5mo ago
iwd requires CONFIG_CRYPTO_USER_API_AEAD, so disabling this would break Wi-Fi for a lot of people.
- ebiggers 5mo ago
  Indeed, iwd is the main reason why general-purpose Linux distros can't disable AF_ALG yet. But many Linux systems are more specialized and don't have wireless connectivity, or they use another wireless daemon such as wpa_supplicant which doesn't have this issue. I'm hoping we can get iwd fixed to use a userspace crypto library, as well. This is something that people could help with. iwd also runs as root, so it would be okay with a CAP_SYS_ADMIN permission check if one were introduced, I think.
TZubiri 5mo ago
YAGNI stocks are rising, Gentoo devs that compile their own kernel probably yeeted this module. Alpine, and MUSL deviants are probably immune to this downswing. DRY looking very bearish, do repeat yourself, do build your own, do use userspace tools even if the kernel has its own version. Not as big a hit on the DRY philosophy as those pip and npm supply chain attacks last couple of weeks though. KISS remains unaffected for the time being.
- MarsIronPI 5mo ago
  I think the issue here is not "Don't Repeat Yourself", but "Don't Reinvent the Wheel". If your wheel is just a circle of wood, you're better off building it yourself than hiring a skilled (or sometimes not so skilled) laborer. Too much overhead and risk.
wolttam 5mo ago
I love this. I think everyone in software should be feeling a tinge of “we should trim the fat” right now - get rid of as much of the old and infrequently used/tested code as we can. Push users towards the better tested alternatives.
- zbentley 5mo ago
  But but but … wE dOnT bREaK uSErsPaCe!
derefr 5mo ago
It'd make a lot of sense to sandbox AF_ALG, then, wouldn't it? At least for userspace-driven invocations. Let the kernel keep its current code-path for kernel-driven invocations, but have the same code unit files also build some other sandboxed form, to be invoked by the crypto-accelerating syscalls. If these syscalls are used by userspace as rarely as you say, the performance impact of this kind of sandboxing wouldn't matter much. And maybe there could be a KCONFIG/boot flag to switch back to using the un-sandboxed code path for userspace invocations too, for enterprises stuck with old software who really care. --- My own thought process on how this could work below (but I'm not a kernel contributor, so you can probably immediately picture a design better than I can): The naive way to do this, would be for the kernel build process to emit a separate AF_ALG userland IPC server as an additional build artifact; to get distros to package this IPC server as a component package of kernel packages; and to set up the sandboxed AF_ALG "kernel bridge" so that it proxies calls through to this IPC server if it exists, and errors out otherwise. (Basically like kfuse, except in this case the only "FUSE servers" are first-party.) But that's a bit painful, organizationally. Puts a lot of work on the distro maintainers' shoulders, that they might just not bother doing. Prone to error. I think there are better alternatives. 1. Maybe the userland syscalls that rely on AF_ALG could instead ground out inside the kernel in a copy of AF_ALG that's been compiled to eBPF? Then that eBPF bytecode could just be embedded into the kernel. 2. Maybe the Linux kernel could consider a facility that would enable it to act as a hybrid microkernel (similar to macOS's XNU) — with arbitrary static sections of the kernel image/kernel modules [or perhaps standalone static ELF binaries embedded within kernel/kmod .data sections] being spawned not as supervisor-mode kthreads doing their own autonomous thing, but rather as unprivileged user-mode kernel threads, running as IPC-servers for the rest of the kernel to talk to? - The rest of the kernel could talk to these "userspace kthreads" via some nonblocking IPC mechanism; but this mechanism wouldn't need to be exposed to userland the way macOS's XPC is; it could be kernel-to-kernel only (where these "userspace kthreads", despite being in userspace, are still fundamentally kernel threads, and so get to participate in it.) - Also, these "userspace kthreads", when they're the active scheduled task, would have the kernel image's read-only sections [or their binary's sections, from within the kernel's .data section] mapped into their address space, since that's the binary they're executing against. But they wouldn't inherit [or the spawning mechanism would actively prune from their task struct] the rest of the kernel's mappings. So they'd have to either use the IPC mechanism, or use regular syscalls, to do anything with the kernel, just like any userspace task.)
amluto 5mo ago
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.
sharts 5mo ago
If it should not exist what’s the rationale for keeping it instead of removing it?
eqvinox 5mo ago
Yeah, so, as we just learned (dirty.frag) the issue isn't algif_aead, it's authencesn and you can exploit it through plain network sockets rather than AF_ALG.

dev_l1x_be 5mo ago

Why is this available in the kernel on a box that does not use ipsec? should this be compile time enabled module instead than a generic solution?

ButlerianJihad 5mo ago
The design philosophy of mainstream Linux distros is not like OpenBSD. Linux distros go to market as maximally capable, maximally interoperable, and maximally available for whatever the users want to do. So there is a lot of "shovelware" that is unnecessarily installed with your base system. A lot of services are enabled that you don't need. A lot of kernel modules are loaded or ready to spring into action as soon as you connect hardware that the kernel recognizes. All this maximizing also increases the system's attack surface, whether local or over the network. Your resources, time and effort increase, to update the system and maintain all those packages. The TCO is high. With OpenBSD, the base system is hardened and the code is audited with security in mind. They only install or enable essential functions. So it's up to the user to dig in, customize it, and add in features that are needed. The good news is that you can do some after-market hardening. Uninstall software that you're not using, and disable non-essential services. Tune your kernel for special-purpose, or general-purpose, but not every-purpose. There are now special distros for containers and VMs with minimal system builds. They are designed to be as small and lightweight as possible. That is a good start in the right direction.
- dev_l1x_be 5mo ago
  Thanks for the explanation. I am wondering if it is possible or does it make sense to have a modular linux that does not have these attack surfaces enabled by default. Alpine is my default solution for most Linux use cases (except when I need GPU support).
  - tosti 5mo ago
    Not "by default", but still Gentoo. My USE= is several lines worth of -this -that -all-the-things. I got rid of wayland, pipewire, pulseaudio, avahi and a shitload of other stuff I don't need. PulseAudio applications can still produce (but not record) audio through apulse and my handcrafted asoundrc

sidewndr46 5mo ago

any idea what software this will break once I turn this kernel configuration off?

deleted 5mo ago
[deleted]
ebiggers 5mo ago
iwd is the main culprit (for systems that use it instead of wpa_supplicant). I think cryptsetup / LUKS also requires it with some non-default options. With the default options, it works fine with the kconfigs disabled. There's not much else, as far as I know. Normally programs just use a userspace library instead, such as OpenSSL.

alpn 5mo ago

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.

dnnddidiej 5mo ago
I wonder can the kernel just remove it and distros put on a compatiability layer.
- TheDong 5mo ago
  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.
  - adrian_b 5mo ago
    I always use only custom compiled kernels on my computers, where I enable only the configuration options that I really need. So the options related to AF_ALG have always been disabled, because I have not encountered an application that needs them, among those that I use. Unfortunately the Linux distributions must enable in their default configuration most options, because they cannot predict what their users will need.

still_grokking 5mo ago

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 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 support cannot be used from user space except through AF_ALG. > * 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 from its memory and just use the cipher handle to perform the cryptographic operations. If the application is cracked an attacker cannot obtain the key material. > * On memory constrained systems like embedded systems, the additional memory footprint of a user space cryptographic library may be too much. As the kernel requires the kernel crypto API to be present, reusing existing code should reduce the memory footprint. I can't judge whether this is a good justification, but there is one.

buckle8017 5mo ago
You should take note that this is written by the person that wrote the bad patch. So grain of salt.
- still_grokking 5mo ago
  I've said I'm not sure about the validity of that reasoning. I've liked it nevertheless for context, as augmentation to parent's post.
- asveikau 5mo ago
  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.

Fr0styMatt88 5mo ago

How did it get in? Isn’t Linus known for being rightfully fussy about what makes it into the kernel? Would be an interesting story.

kasabali 5mo ago
Linus has had been fussy about maybe like 5% of the things because even then he couldn't keep up with the sheer volume. Nowadays it's more like 1‰

eqvinox 5mo ago

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.]

angry_octet 5mo ago
Better implemented as another user space process than in the kernel.
- eqvinox 5mo ago
  You can't access TPMs that way.
  - wetpaws 5mo ago
    [dead]
  - angry_octet 5mo ago
    Most of the Linux kernel crypto is not touching the TPM. If there is a TPM task, only that code should be in kernel, and it should be accessed from user space by a process with the appropriate token.
    - eqvinox 5mo ago
      Yes, AF_ALG is exposing too many things, like authencesn, which has zero reason for being userspace accessible. It's a crypto mode specific to IPsec. However, > it should be accessed from user space by a process with the appropriate token. That is AF_ALG. The operations it offers are what you need for full coverage. The issues with it are two: - usage specific crypto in the kernel implements the same interfaces, and it doesn't have a filter for that, as mentioned above. It's not offering too many operations, it's offering too many algorithms. - it's trying to be fast. I guess people also want to use crypto accelerators through it. (Which is kinda related to TPMs, there is accelerator hardware with built-in protected key storage...) The CVE we're looking at here is in the intersection of both of these.

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 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.
- 400thecat 5mo ago
  is CONFIG_CRYPTO_USER_API needed for hw acceleration for cryptsetup (dm-crypt) disk encryption ?
  - ebiggers 5mo ago
    No, dm-crypt just calls the kernel's crypto code directly.
strenholme 5mo 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.

l1k 5mo ago

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-service-and-why-you-should-use-it-in-your-next-application/ https://blog.cloudflare.com/the-linux-kernel-key-retention-s... https://www.youtube.com/watch?v=7djRRjxaCKk https://www.youtube.com/watch?v=7djRRjxaCKk https://www.youtube.com/watch?v=lvZaDE578yc 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 crypto/asymmetric_keys/ in the kernel and the author/presenter in the first two links is another co-maintainer.

ebiggers 5mo ago
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).
- ngomez 5mo ago
  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-Cunning-With-CNG-Soliciting-Secrets-From-SChannel.pdf https://blackhat.com/docs/us-16/materials/us-16-Kambic-Cunni...
  - lostmsu 5mo ago

anabis 5mo ago

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.

KnuthIsGod 5mo ago

Removing this will make the friendly spooks at NSA very sad....

tosti 5mo ago
No, it'd make me sad. If they're lurking in there and we can do without, I'm happy to always have my own .config If this gets removed, they'll creep in somewhere we can't find them for a while.

tosti 5mo ago

I think it would be reasonable to deprecate af_alg in favor of a character device. It's more accessible that way. The downside is that the maintainers hate adding new ioctls. I think that's fair. But I don't think a "regular" device node would cover the functionality userland expects. That said, elsewhere ITT it's pointed out there are only a few use cases so far.

SeriousM 5mo ago

I was completely unaware of https://syzbot.org https://syzbot.org, thanks for sharing! > syzbot system continuously fuzzes main Linux kernel branches and automatically reports found bugs to kernel mailing lists. syzbot dashboard shows current statuses of bugs. All syzbot-reported bugs are also CCed to syzkaller-bugs mailing list. Direct all questions to syzkaller@googlegroups.com.

400thecat 5mo ago

can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum

m3nu 5mo ago

What other kernel modules would you suggest disabling that aren't used usually?

WhyNotHugo 5mo ago

iwd requires CONFIG_CRYPTO_USER_API_AEAD, so disabling this would break Wi-Fi for a lot of people.

ebiggers 5mo ago
Indeed, iwd is the main reason why general-purpose Linux distros can't disable AF_ALG yet. But many Linux systems are more specialized and don't have wireless connectivity, or they use another wireless daemon such as wpa_supplicant which doesn't have this issue. I'm hoping we can get iwd fixed to use a userspace crypto library, as well. This is something that people could help with. iwd also runs as root, so it would be okay with a CAP_SYS_ADMIN permission check if one were introduced, I think.

TZubiri 5mo ago

YAGNI stocks are rising, Gentoo devs that compile their own kernel probably yeeted this module. Alpine, and MUSL deviants are probably immune to this downswing. DRY looking very bearish, do repeat yourself, do build your own, do use userspace tools even if the kernel has its own version. Not as big a hit on the DRY philosophy as those pip and npm supply chain attacks last couple of weeks though. KISS remains unaffected for the time being.

MarsIronPI 5mo ago
I think the issue here is not "Don't Repeat Yourself", but "Don't Reinvent the Wheel". If your wheel is just a circle of wood, you're better off building it yourself than hiring a skilled (or sometimes not so skilled) laborer. Too much overhead and risk.

wolttam 5mo ago

I love this. I think everyone in software should be feeling a tinge of “we should trim the fat” right now - get rid of as much of the old and infrequently used/tested code as we can. Push users towards the better tested alternatives.

zbentley 5mo ago
But but but … wE dOnT bREaK uSErsPaCe!

derefr 5mo ago

It'd make a lot of sense to sandbox AF_ALG, then, wouldn't it? At least for userspace-driven invocations. Let the kernel keep its current code-path for kernel-driven invocations, but have the same code unit files also build some other sandboxed form, to be invoked by the crypto-accelerating syscalls. If these syscalls are used by userspace as rarely as you say, the performance impact of this kind of sandboxing wouldn't matter much. And maybe there could be a KCONFIG/boot flag to switch back to using the un-sandboxed code path for userspace invocations too, for enterprises stuck with old software who really care. --- My own thought process on how this could work below (but I'm not a kernel contributor, so you can probably immediately picture a design better than I can): The naive way to do this, would be for the kernel build process to emit a separate AF_ALG userland IPC server as an additional build artifact; to get distros to package this IPC server as a component package of kernel packages; and to set up the sandboxed AF_ALG "kernel bridge" so that it proxies calls through to this IPC server if it exists, and errors out otherwise. (Basically like kfuse, except in this case the only "FUSE servers" are first-party.) But that's a bit painful, organizationally. Puts a lot of work on the distro maintainers' shoulders, that they might just not bother doing. Prone to error. I think there are better alternatives. 1. Maybe the userland syscalls that rely on AF_ALG could instead ground out inside the kernel in a copy of AF_ALG that's been compiled to eBPF? Then that eBPF bytecode could just be embedded into the kernel. 2. Maybe the Linux kernel could consider a facility that would enable it to act as a hybrid microkernel (similar to macOS's XNU) — with arbitrary static sections of the kernel image/kernel modules [or perhaps standalone static ELF binaries embedded within kernel/kmod .data sections] being spawned not as supervisor-mode kthreads doing their own autonomous thing, but rather as unprivileged user-mode kernel threads, running as IPC-servers for the rest of the kernel to talk to? - The rest of the kernel could talk to these "userspace kthreads" via some nonblocking IPC mechanism; but this mechanism wouldn't need to be exposed to userland the way macOS's XPC is; it could be kernel-to-kernel only (where these "userspace kthreads", despite being in userspace, are still fundamentally kernel threads, and so get to participate in it.) - Also, these "userspace kthreads", when they're the active scheduled task, would have the kernel image's read-only sections [or their binary's sections, from within the kernel's .data section] mapped into their address space, since that's the binary they're executing against. But they wouldn't inherit [or the spawning mechanism would actively prune from their task struct] the rest of the kernel's mappings. So they'd have to either use the IPC mechanism, or use regular syscalls, to do anything with the kernel, just like any userspace task.)

amluto 5mo ago

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.

sharts 5mo ago

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

eqvinox 5mo ago

Yeah, so, as we just learned (dirty.frag) the issue isn't algif_aead, it's authencesn and you can exploit it through plain network sockets rather than AF_ALG.