ebiggers

7 ms·

1.
by ebiggers 5mo ago
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
2.
by 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_supplica
3.
by ebiggers 5mo ago
No, dm-crypt just calls the kernel's crypto code directly.
4.
by 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
5.
by ebiggers 5mo ago
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
6.
by 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 c
7.
by 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 no
8.
by ebiggers 5mo ago
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
9.
by ebiggers 3y ago
It may have been, but security impact is often not recognized right away. The older report was not sent to security@kernel.org and did not include a root cause analysis.
10.
by ebiggers 3y ago
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
11.
by ebiggers 3y ago
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.
12.
by ebiggers 4y ago
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 meth
13.
by ebiggers 6y ago
> 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 th
14.
by ebiggers 7y ago
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
15.
by ebiggers 7y ago
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.
16.
by ebiggers 7y ago
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://syz
17.
by ebiggers 8y ago
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 pro
18.
by ebiggers 8y ago
(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) w
19.
by ebiggers 8y ago
You can read about some of the other options considered here: https://marc.info/?l=linux-crypto-vger&m=152573520705012 . But in the end, a new ChaCha-based mode suitable for disk encryption ( https://eprint.ia
20.
by ebiggers 8y ago
There's some missing context if you read just Dr. Ashur's email and not the rest of the thread. The reason I added Speck to the Linux kernel's crypto API is unrelated to the proposed/rejected ISO standard, but rather be