ebiggers · HackerTrans

il y a 3 moisdiscuss

I don't see those eBPF or microkernel ideas as being particularly realistic! But there are some simple ways AF_ALG's attack surface could be reduced (as an intermediate step to disabling it entirely), like requiring CAP_SYS_ADMIN and/or limiting the algorithms to a specific list.

ebiggers

il y a 3 moisdiscuss

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.

ebiggers

il y a 3 moisdiscuss

No, dm-crypt just calls the kernel's crypto code directly.

ebiggers

il y a 3 moisdiscuss

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

ebiggers

il y a 3 moisdiscuss

It doesn't seem to actually get used that way in practice. ALG_SET_KEY_BY_KEY_SERIAL didn't even appear until just a few years ago. And either way, if the interface allows you to overwrite the su binary, whether it theoretically could provide some other security benefit becomes kind of irrelevant.

ebiggers

il y a 3 moisdiscuss

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.

ebiggers

il y a 3 moisdiscuss

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.

ebiggers

il y a 3 moisdiscuss

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.

ebiggers

il y a 3 ansdiscuss

It may have been, but security impact is often not recognized right away. The older report was not sent to [email protected] and did not include a root cause analysis.

ebiggers

il y a 3 ansdiscuss

This is a great example of why so few people want to be a Linux kernel maintainer. Not only is it largely a thankless "job" where you get blamed for issues you didn't cause and are expected to do much of the work on your own time, but you can potentially get a misleading hit piece published about you and posted to Hacker News just for doing your job.

IMO, what the maintainer did (taking authorship and crediting the original author/reporter via Reported-by, after rewriting the entire patch including the commit message) was in line with kernel conventions. The lines are a bit blurry, and I think keeping the original author/reporter as at least a Co-developer would also have been acceptable. Still, people sometimes complain if they are kept as the author or co-developer if their patch is rewritten, as they don't want to "own" that rewritten patch and take blame for any issues in it. So pick your poison.

Ideally, more time would have been taken to work with the original author/reporter to get their patch in shape. Unfortunately, there isn't always time for that. In this case, the bug was reported to [email protected] as a security vulnerability, so that throws much of the usual process out the window; it needed to be fixed quickly. The maintainer went out of their way to get it fixed quickly, in a better way, and even added unit tests for it later. The original author/reporter was credited in both the fix commit and the pull request merge commit. Also note that the maintainer's commit is dated June 7 and was merged into mainline on June 9. So AFAICS, it predated the original author/reporter sending a revised patch; it postdated only the first patch.

ebiggers

il y a 3 ansdiscuss

How were you comparing ISA-L and libdeflate? For decompression I've found that the latest version of libdeflate is slightly faster than ISA-L.

ebiggers

il y a 4 ansdiscuss

Note that libdeflate has used essentially the same method since 2016 (https://github.com/ebiggers/libdeflate/blob/v0.4/lib/adler32...), though I recently switched it to use a slightly different method (https://github.com/ebiggers/libdeflate/blob/v1.12/lib/x86/ad...) that performs more consistently across different families of x86 CPUs.

ebiggers

il y a 6 ansdiscuss

> In this somewhat unusual case, the problem was found and corrected in the Linux kernel through a typical bug-fix process and not handled as a security vulnerability, so no CVE was assigned.

This isn't unusual. This is actually the usual case.

The unusual thing here is actually that someone downstream noticed they were missing a fix (probably because its LTP regression test was failing, which is also unusual because most kernel fixes don't have an LTP regression test).

More commonly, no one notices and these bugs never get fixed in downstream kernels that aren't staying up to-date with LTS; and there is never a CVE, an oss-security post, a Hacker News thread, etc. But these bugs are still there.

ebiggers

il y a 7 ansdiscuss

Well, the longer that vulnerabilities are kept secret, the longer that users are unable to take any action to protect themselves, and the less incentive that vendors have to roll out fixes quickly and to prevent vulnerabilities in the first place. See the Project Zero disclosure FAQ: https://googleprojectzero.blogspot.com/p/vulnerability-discl...

ebiggers

il y a 7 ansdiscuss

SELinux actually does significantly reduce the kernel attack surface on Android, and it has made a lot of kernel vulnerabilites unexploitable on Android. This particular bug was simply one in the remaining attack surface.

ebiggers

il y a 7 ansdiscuss

syzbot is already fuzzing the latest two stable kernels and has found hundreds of bugs, including lots of use-after-frees. All these bugs are listed here:

- https://syzkaller.appspot.com/linux-4.14 - https://syzkaller.appspot.com/linux-4.19

As far as I know, no one is doing anything with the syzbot bugs against stable kernels directly, since no company using Linux is paying anyone to do it as their job. But some are getting fixed; e.g., some get reported against mainline too, then fixed and backported.

ebiggers

il y a 7 ansdiscuss

AFAICS, this was exposed by the addition of sockfs_setattr() in v4.10. So it's incorrect to claim that kernels older than that are vulnerable, even though the code being fixed was older.

Also, note that there may not actually be a proof-of-concept exploit yet, beyond a reproducer causing a KASAN splat. When people request a CVE for a use-after-free bug they usually just assume that code execution may be possible. (Exploits can be very creative.)

ebiggers

il y a 7 ansdiscuss

(I'm one of the authors of the blog post)

We considered it, of course, along with many other block ciphers. However, heavily optimized Threefish-256 is 22.6 cycles per byte on Cortex-A7 (by far the most common CPU this is needed on) which is over twice as slow as Adiantum. Threefish-512 and Threefish-1024 would be much slower still. We're already at the borderline of the performance needed to actually get all Android devices encrypted, so over 2x worse performance is a no-go.

Threefish also wasn't published as a standalone block cipher but rather was part of Skein, which lost the SHA-3 competition. Therefore it hasn't received as much cryptanalysis as ChaCha and AES, and probably won't get much more in the future.

Finally, note that unlike Adiantum, Threefish isn't a wide-block cipher, where flipping one bit in the sector scrambles all other bits. So comparing its complexity directly to Adiantum's is somewhat unfair. Other wide-block modes such as HCH and HCTR are also more complex than narrow-block modes.

comments