For a second I though this was something bad for my computer. But is mainly a server permissions issue it seems. Will patch my server when I’m home though
drkt@scribe.disroot.org
on 30 Apr 15:46
nextcollapse
What do you mean? If you use Linux on your computer, it’s also relevant. Any program can quietly drop a root shell from any privilege level in 10 lines of python.
This attack must be run locally. The attacker must already have user access. They can then escalate privileges using this. Meaning your box must already be compromised for this to work. Still serious, but no need to panic in most cases.
possiblylinux127@lemmy.zip
on 30 Apr 21:26
collapse
Sure don’t patch a quiet and easy root shell escalation because it is, by itself, not a remote exploit. I sure do hope you trust every single piece of software running on your computer.
thesmokingman@programming.dev
on 30 Apr 19:51
collapse
I think you’re displaying a very big gap between understanding risk assessment and understanding task completion. So far I have not seen anyone say they would not complete the task. I have seen people complete risk assessment. Risk assessment does not mean I will not do something, it just reflects the urgency with which I will do it. Most self-hosted users can safely apply basic risk assessment to see, while the impact may be high, the likelihood is low. Obviously the likelihood increases the more hands off you are with, say, unattended container updates for things that can escape containers or access the underlying system. Should most self-hosted users literally drop everything, rush home, and apply the patch? No, basic risk assessment does not merit that. Should everyone apply the patch? Yes.
InnerScientist@lemmy.world
on 30 Apr 20:03
collapse
I have a mix of Debian and Ubuntu servers. I’ll update manually anyway but for future cases, would unattended-upgrades set to security upgrades run daily be enough to stop this type of issue?
This is a kernel bug, unattended-upgrades will take care of installing the new kernel once the fix is published, but you still have to reboot to load it. I’ve set up a cron job that runs needrestart nightly and reboots my servers if there is a pending kernel upgrade [1]
possiblylinux127@lemmy.zip
on 30 Apr 21:24
collapse
Unattended-upgrades has a config option to auto reboot
pipe01@programming.dev
on 30 Apr 18:02
nextcollapse
Why is the PoC obfuscated?
HyperfocusSurfer@lemmy.dbzer0.com
on 30 Apr 18:13
collapse
Dumb question but… It says that patches were committed to mainline on April 1st. How would one know if their distro has already fixed this via updates or not? I run a rolling-release distro on my desktop and laptop, and usually update once every week (or two at most) so have already ran updates 2 or 3 times since the patch was deployed. Am I likely good? If I’m not, is running updates all I need to do to be good? How would I know?
determinist@kbin.earth
on 30 Apr 19:37
nextcollapse
I ran the script today and my system is vulnerable.
Cachyos, all up to date.
thesmokingman@programming.dev
on 30 Apr 19:56
nextcollapse
The only guaranteed fix is in the kernel. You’ll want to check your distro for the CVE. The disclosers very happily bring up all the distros affected but do not seem to have reached out to any of them to also patch. The CVE itself is still waiting for NVD analysis beyond its base score.
I’m not actively saying they did anything wrong but I am saying they’re blowing smoke about responsible disclosure.
ozymandias117@lemmy.world
on 30 Apr 20:29
nextcollapse
Yeah… It seems like they only reached out to the kernel, and not to any distros…
They also disclosed after 37 days rather than the more standard 90 days for everyone to patch
They sell a vulnerability discovery program. IMO, they did this dubious responsable disclousure to get the extra marketing.
ozymandias117@lemmy.world
on 30 Apr 20:18
collapse
Check uname -r
If you’re on 6.19.12 or newer (7.0.1 if they’ve already bumped to 7) you’re definitely safe
If you don’t have a safe kernel,
A better solution referenced below than a module blacklist is to set initcall_blacklist=algif_aead_init in your kernel boot parameters. There is not a generic way to do this across distros, so you will need to look it up for your case
~~If you don’t have the updated kernel, you can
echo “install algif_aead /bin/false” > /etc/modprobe.d/disable-algif.conf and reboot.
That ensures the buggy module cannot be loaded until you have an updated kernel~~
Thank you for the info, I will look into it when I get home tonight.
StripedMonkey@lemmy.zip
on 30 Apr 22:59
nextcollapse
I continue to protest against this claim. Blacklisting the kernel module does not work for a bunch of distributions including Alma, Rocky, RHEL and others because they have this module built into the kernel. There’s no module to remove. You must use a syscall blacklist or similar mechanism to disable this.
ozymandias117@lemmy.world
on 30 Apr 23:02
collapse
I’m working off the knowledge that OP is using a rolling release, so is likely fixed by that for them.
(Arch based, Cachy, and OpenSUSE Tumbleweed all have it as a module, and are the most commonly suggested. Fedora fixed it 2 weeks ago since they follow mainline, so I’d expect Bazzite to have it too. If they’re using Debian Sid/Testing, it’s both fixed and a module)
My personal suggestion would be to add initcall_blacklist=algif_aead_init to your kernel arguments. Ebpf is cool, but not a very trivial solution.
I understand the suggestion might apply to a random, unspecified distro but I disapprove of both the exploit authors and the general Internet suggesting fixes that don’t apply to every distro (including copy.fail’s AI slop RHEL distro that doesn’t exist) without caveating it.
The kernel module blacklist won’t work for every situation, if you’re not being specific in telling people where it applies, it’s best to suggest a solution that actually works regardless of distro or explain how to validate when it applies but nobody is doing that.
ozymandias117@lemmy.world
on 01 May 00:19
collapse
Giving a better solution is certainly useful.
I’d used initcall_debug before, but not initcall_blacklist
possiblylinux127@lemmy.zip
on 01 May 00:57
collapse
You could just install security updates
ozymandias117@lemmy.world
on 01 May 01:59
collapse
They aren’t available on all releases - the people that found the issue didn’t really follow responsible disclosure, so distros didn’t have time to fix it
They will fix it over the next couple days, but if you need a fix now, those are the ways to protect yourself until security updates make it out
possiblylinux127@lemmy.zip
on 01 May 02:28
collapse
All major distros have been patched as of writing this (you are welcome to correct me if I’m wrong)
ozymandias117@lemmy.world
on 01 May 02:30
collapse
The ones I was watching look like there’s an update as of an hour ago, but there wasn’t at the time of the post
Need to check Raspbian still, being on self hosting
laughs in unattended-updates. On Debian, not Crapuntu
MrRazamataz@lemmy.razbot.xyz
on 30 Apr 23:27
nextcollapse
will it reboot to apply the kernel changes?
julianwgs@discuss.tchncs.de
on 01 May 05:58
collapse
unattended-updates will not reboot unless configured. The system needs to reboot to patch the issue, because it is a kernel patch. None of the major distros had a patch ready.
This disclosure has been rushed for the views and hype IMO, none of the big distros had fixes ready to go on this this morning.
purplemonkeymad@programming.dev
on 01 May 06:53
nextcollapse
Yea I didn’t think the post was that professional. Also the “unminified” version is just the minified with more white space. It still has poor names and no explanation of the binary blob.
I haven’t checked too deeply but I think fedora dropped the affected system between kernels 6.6 and 6.12 somewhere. 6.12+ appear to not have the modules.
Not too surprising given the system has been deprecated for a long time.
aphonefriend@lemmy.dbzer0.com
on 01 May 03:22
collapse
threaded - newest
For a second I though this was something bad for my computer. But is mainly a server permissions issue it seems. Will patch my server when I’m home though
What do you mean? If you use Linux on your computer, it’s also relevant. Any program can quietly drop a root shell from any privilege level in 10 lines of python.
This attack must be run locally. The attacker must already have user access. They can then escalate privileges using this. Meaning your box must already be compromised for this to work. Still serious, but no need to panic in most cases.
A local compromise happens more than you think
<img alt="" src="https://lemmy.world/pictrs/image/b16b9f8e-e063-4113-bc73-1fb16b58d4e1.png">
/c/selfhosted moment
Sure don’t patch a quiet and easy root shell escalation because it is, by itself, not a remote exploit. I sure do hope you trust every single piece of software running on your computer.
I think you’re displaying a very big gap between understanding risk assessment and understanding task completion. So far I have not seen anyone say they would not complete the task. I have seen people complete risk assessment. Risk assessment does not mean I will not do something, it just reflects the urgency with which I will do it. Most self-hosted users can safely apply basic risk assessment to see, while the impact may be high, the likelihood is low. Obviously the likelihood increases the more hands off you are with, say, unattended container updates for things that can escape containers or access the underlying system. Should most self-hosted users literally drop everything, rush home, and apply the patch? No, basic risk assessment does not merit that. Should everyone apply the patch? Yes.
xkcd.com/1200/
<img alt="" src="https://imgs.xkcd.com/comics/authorization.png">
It affects any device that can use raw sockets in the kernel. Patch everything.
“mainly”, it is a ‘lower’ priority for single use local computers
I have a mix of Debian and Ubuntu servers. I’ll update manually anyway but for future cases, would unattended-upgrades set to security upgrades run daily be enough to stop this type of issue?
This is a kernel bug, unattended-upgrades will take care of installing the new kernel once the fix is published, but you still have to reboot to load it. I’ve set up a cron job that runs needrestart nightly and reboots my servers if there is a pending kernel upgrade [1]
Unattended-upgrades has a config option to auto reboot
Why is the PoC obfuscated?
Probably looks more 1337 this way 🤣
There’s a readable version in the issues, tho: github.com/theori-io/…/54#issuecomment-4351460190
Dumb question but… It says that patches were committed to mainline on April 1st. How would one know if their distro has already fixed this via updates or not? I run a rolling-release distro on my desktop and laptop, and usually update once every week (or two at most) so have already ran updates 2 or 3 times since the patch was deployed. Am I likely good? If I’m not, is running updates all I need to do to be good? How would I know?
I ran the script today and my system is vulnerable.
Cachyos, all up to date.
The only guaranteed fix is in the kernel. You’ll want to check your distro for the CVE. The disclosers very happily bring up all the distros affected but do not seem to have reached out to any of them to also patch. The CVE itself is still waiting for NVD analysis beyond its base score.
I’m not actively saying they did anything wrong but I am saying they’re blowing smoke about responsible disclosure.
Yeah… It seems like they only reached out to the kernel, and not to any distros…
They also disclosed after 37 days rather than the more standard 90 days for everyone to patch
They sell a vulnerability discovery program. IMO, they did this dubious responsable disclousure to get the extra marketing.
Check
uname -rIf you’re on 6.19.12 or newer (7.0.1 if they’ve already bumped to 7) you’re definitely safe
If you don’t have a safe kernel, A better solution referenced below than a module blacklist is to set
initcall_blacklist=algif_aead_initin your kernel boot parameters. There is not a generic way to do this across distros, so you will need to look it up for your case~~If you don’t have the updated kernel, you can
echo “install algif_aead /bin/false” > /etc/modprobe.d/disable-algif.confand reboot.That ensures the buggy module cannot be loaded until you have an updated kernel~~
Thank you for the info, I will look into it when I get home tonight.
I continue to protest against this claim. Blacklisting the kernel module does not work for a bunch of distributions including Alma, Rocky, RHEL and others because they have this module built into the kernel. There’s no module to remove. You must use a syscall blacklist or similar mechanism to disable this.
I’m working off the knowledge that OP is using a rolling release, so is likely fixed by that for them. (Arch based, Cachy, and OpenSUSE Tumbleweed all have it as a module, and are the most commonly suggested. Fedora fixed it 2 weeks ago since they follow mainline, so I’d expect Bazzite to have it too. If they’re using Debian Sid/Testing, it’s both fixed and a module)
If you’re using something else, this eBPF filter is probably your best bet github.com/Dabbleam/CVE-2026-31431-mitigation
My personal suggestion would be to add
initcall_blacklist=algif_aead_initto your kernel arguments. Ebpf is cool, but not a very trivial solution.I understand the suggestion might apply to a random, unspecified distro but I disapprove of both the exploit authors and the general Internet suggesting fixes that don’t apply to every distro (including copy.fail’s AI slop RHEL distro that doesn’t exist) without caveating it.
The kernel module blacklist won’t work for every situation, if you’re not being specific in telling people where it applies, it’s best to suggest a solution that actually works regardless of distro or explain how to validate when it applies but nobody is doing that.
Giving a better solution is certainly useful.
I’d used initcall_debug before, but not initcall_blacklist
You could just install security updates
They aren’t available on all releases - the people that found the issue didn’t really follow responsible disclosure, so distros didn’t have time to fix it
They will fix it over the next couple days, but if you need a fix now, those are the ways to protect yourself until security updates make it out
All major distros have been patched as of writing this (you are welcome to correct me if I’m wrong)
The ones I was watching look like there’s an update as of an hour ago, but there wasn’t at the time of the post
Need to check Raspbian still, being on self hosting
laughs in unattended-updates. On Debian, not Crapuntu
will it reboot to apply the kernel changes?
unattended-updates will not reboot unless configured. The system needs to reboot to patch the issue, because it is a kernel patch. None of the major distros had a patch ready.
This doesn’t affect my org at all. Our SAAS providers already demand ssh root access on our Linux VMs so their applications work.
Disable the sandbox bit and it’s bobbitted, right ?
thehackernews.com/…/new-linux-copy-fail-vulnerabi…
This disclosure has been rushed for the views and hype IMO, none of the big distros had fixes ready to go on this this morning.
Yea I didn’t think the post was that professional. Also the “unminified” version is just the minified with more white space. It still has poor names and no explanation of the binary blob.
The patches where proposed over a month ago and the patch to the kernel was commited on 1th of April.
Either the Vulnerability was not proper communicated to the distro maintainers or they were the ones sleeping.
This was probably executed as a responsible discllsure where clear timelines and release dates get communicated from the beginning.
I find it hard to blame the security team here when there was 1 month of time between first commited patch and release of the PoC.
Interesting enough systems running SELinux seem to be potentially protected against this assuming SELinux is configured to block AF_ALG
On Android AF_ALG is locked down with SElinux so it shouldn’t be impacted
Nothing much to do for me. Just apply patches as normal.
Edit: I wonder how bad is it on Android
I don’t think af_alg is exposed to non-root users on android.
I wished android is affected but no
I haven’t checked too deeply but I think fedora dropped the affected system between kernels 6.6 and 6.12 somewhere. 6.12+ appear to not have the modules.
Not too surprising given the system has been deprecated for a long time.
Does this affect Synology NASs?
Probably. But it’s unlikely to be exploited as the attack needs shell access for the bad operation, not just any buffer.