331–340 of 545 posts
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. Th…
> 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.
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. Th…
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.
As of now the submission title is simply “Copy Fail”.
Given the severity of the exploit, can we edit the Title to add some context that it’s a major Linux vulnerability?
Eg the other submissions say this : “Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.”
Earlier quoted context omitted.
Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority. https://ubuntu.com/security/cves/about#priority > Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.
if your model is that linux is just about single-user desktops, this local exploit isn't too bad. or if your model is nothing but DB servers or the like. mystifying to me that shared, multi-user machines are not thought of. for instance, I administer a system with 27k users - people who can login. even if only 1/10,000 of them are curious/malicious/compromised, we (Canadian national research HPC systems) are at risk.…
For example, if you have passwordless sudo, you've already got a widely known LPE vulnerability lurking on your system.
Earlier quoted context omitted.
it's advertising their AI, not the talents of their humans :D
People are confusing the presentation layer with the content, just a surface layer analysis. Basically people are feeling so burnt by reading AI fluff that they make a rushed judgement.
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. Th…
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 alg…
zgrep CONFIG_CRYPTO_USER_API /proc/config.gz