RHEL is listing this as fix deferred for RHEL 8 and 9.
They've bumped the severity and 8/9/10 are now 'affected'. Hope a patch comes soon!
Copy Fail
361–370 of 545 posts
Re: Copy Fail
#362Earlier quoted context omitted.
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-s... https://www.youtube.com/watch?v=7djRRjxaCKk 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 cr…
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
As Eric has correctly stated above, we believe iwd (Intel Wireless Daemon), or rather the ell library it relies on (Embedded Linux Library) is the only relatively widespread user space application relying on it.
Re: Copy Fail
#363Earlier quoted context omitted.
PoC is also x86_64 only and not arm.
fixed: https://github.com/tgies/copy-fail-c
Thanks! Will give it a try a bit later.
(HN algorithms have killed some of your comments, perhaps because you posted the same URL too many times from a relatively new account? I’ve vouched for you, but keep in mind that it triggers antispam.)
---
Edit: naturally, no luck:
$ ./exploit /system/bin/ping
[+] target: /system/bin/ping
[+] payload: 2112 bytes (528 iterations)
socket(AF_ALG): Permission denied
patch_chunk failed at offset 0
Re: Copy Fail
#364Earlier quoted context omitted.
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 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 sup…
You should take note that this is written by the person that wrote the bad patch. So grain of salt.
But is it true or not? Whoever wrote it. (for objective truth the subjects are unimportant)
Re: Copy Fail
#365It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros. https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred" https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-3143…
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.
Local access is a bit of a misnomer though, a vulnerable website can be tricked into running a script
Re: Copy Fail
#366Earlier quoted context omitted.
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.…
> if your model is that linux is just about single-user desktops, this local exploit isn't too bad. For example, if you have passwordless sudo, you've already got a widely known LPE vulnerability lurking on your system.
Only for your user, and it means a keylogger on the system if it gets rooted can't pull your password to try on other machines. Personally I always either login as root or use passwordless sudo.
Re: Copy Fail
#367Earlier quoted context omitted.
I'm sure lots of people have heard of CVEs, but have you actually read many? LPE is an extremely common term. It's like not knowing RCE. These are the terms used.
I'll raise my hand here and risk downvotes from very smart people who are smarter than me, but I've heard of CVE but not LPE or RCE. I know what the latter two terms are but am not used to seeing them in acronyms. So what's missing is that keeping up-to-date with CVEs is important and some CVEs are Internet-nerd famous. Remember Heartbleed? Even some casual gamers I know had heard of it. And everyone who's mildly ser…
To be clear, I'm not suggesting that you if have heard of CVEs therefor you must have heard of LPE. I'm saying if you have read many of them you would have seen these terms.
I obviously do not expect someone who has merely heard of various CVEs before to know anything about the contents of those CVEs. The other poster said they had "read many CVEs", which I took to mean they have read many CVE disclosures, where the term is extremely common. Perhaps they meant that they've read about CVEs, in which case I can see why the term would not be on their radar.
Re: Copy Fail
#368Earlier quoted context omitted.
> if your model is that linux is just about single-user desktops, this local exploit isn't too bad. For example, if you have passwordless sudo, you've already got a widely known LPE vulnerability lurking on your system.
hmm have i missed anything?
Any program on your computer can just run "sudo" to escalate itself.
Re: Copy Fail
#369Earlier quoted context omitted.
How about SELinux, like on Android?
To even get the su binary on Android you have to patch the OS. So this exploit can't work on Android. Because there is no su binary to target. Update: Just tried it on Termux and as expected even creating an AF_ALG socket requires root access.
The specific exploit payload for the POC relies on a su binary. The vuln is ambivalent and other non-su paths will exist.
Re: Copy Fail
#370I wasn't able to unload algif_aead on RHEL 9/10 because it's built in, rather than a module. So here the next-best thing I found: Disable AF_ALG via systemd. Needs drop-ins for all exposed services. Here an Ansible playbook that covers ssdh and user@, which are the main ones usually. https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...
FYI RHEL's SELinux policy blocks AF_ALG socket creation for confined services out of the box. But disabling via RestrictAddressFamilies= unit option, or initcall_blacklist= kernel parameter, seems to be a good mitigation for unconfined services, users and containers.