#copyfail
-
@glent in my experience the gatekeeping doesnt happen at the sysadmin level. sysadmin has a broad surface full of entry level positions, and theres mountains of shit you can do to turn a linux noob into a linux turbonerd.
at the end of the day, besides the intra-corporate bureaucracy, the more someone knows about the systems they manage, the better.
-
@elebertus they are absolutely one of them, sure - chuck in some openclaw malicious skills and youre off to the races
-
just to chime in on the copyfail thing, while, yes, it is a very big deal, the prerequisite is that you have a shell on the box you wish to exploit.
so keep that in mind when doing risk register stuff.
attackers will aim for shit like jumpboxes, shared hosting environments, multi-tennancy environments, and places they can get a shell, then move laterally to get you.
shops doing yolo devops are gonna get targeted, and I wouldnt be surprised to see openclaw malicious skills too
@Viss It might also become a big deal for IoT devices that are running linux and give you shell access to a very limited user account for configuration or diagnostic purposes.
Devices like that rarely get patched.
-
yes, i can help,
phobos has your back, remember?
@Viss SAVE ME VISS!!!
-
@Viss It might also become a big deal for IoT devices that are running linux and give you shell access to a very limited user account for configuration or diagnostic purposes.
Devices like that rarely get patched.
@Mustardfacial it'll depend entirely on the kernel: https://ubuntu.com/security/CVE-2026-31431
-
@Mustardfacial it'll depend entirely on the kernel: https://ubuntu.com/security/CVE-2026-31431
@Viss I don’t have enough fingers or toes to count how many vendor-supplied appliances run on Ubuntu.
But yes, the older IoT devices won’t be affected, but I’ve seen my fair share of them which are not much more than a raspberry pi and a couple of relays
-
yes, i can help,
phobos has your back, remember?
this fixed it for me:
cat >/etc/modprobe.d/disable-algif-aead.conf <<'EOF'
install algif_aead /bin/false
blacklist algif_aead
EOFdepmod -a
rmmod algif_aead
i tested with this: https://github.com/rootsecdev/cve_2026_31431
-
just to chime in on the copyfail thing, while, yes, it is a very big deal, the prerequisite is that you have a shell on the box you wish to exploit.
so keep that in mind when doing risk register stuff.
attackers will aim for shit like jumpboxes, shared hosting environments, multi-tennancy environments, and places they can get a shell, then move laterally to get you.
shops doing yolo devops are gonna get targeted, and I wouldnt be surprised to see openclaw malicious skills too
@Viss so, yeah, about that?
You actually 100% do not need a shell to exploit. Maybe to gain root, but not necessarily.
You just need something that calls the crypto API in a way that creates a scatterlist with the broken function.
Which can be done by literally any program in userland.
If anyone needs me, I'm going to be chugging bottles of hemlock and strychnine and bleach.
-
right now, every single remote code vuln that will lead to command injection or rce will make this #copyfail thing a very very big deal.
so all those qa servers and staging servers and test boxes you think nobody gives a shit about that are just flapping out there in the public, not being logged, not in the siem, not getting alerted on, not getting patched?
all those are gonna catch the "oops attackers overwrote sshd to steal creds" disease.
or cryptominers. or proxies.
@Viss I keep saying at work "it should be considered production the second it's on the network", but it gets shot down because of ... existing PROCESSES. The easy, human, tribal knowledge shit that we could fix with the snap of our fingers and a couple meetings.
-
@Viss so, yeah, about that?
You actually 100% do not need a shell to exploit. Maybe to gain root, but not necessarily.
You just need something that calls the crypto API in a way that creates a scatterlist with the broken function.
Which can be done by literally any program in userland.
If anyone needs me, I'm going to be chugging bottles of hemlock and strychnine and bleach.
@rootwyrm im sure youre right, and that there will be edge cases where some one-off webhosted thinger or weirdo node app bullshit or custom binary doodad will have some path to trigger this thing - but the most commonly exploited scenario based on what ive seen the last few years in consulting land is gonna be shops with very lax security, shared accounts, injectable automated processing, ci/cd pipelines, and llm craps
-
@rootwyrm im sure youre right, and that there will be edge cases where some one-off webhosted thinger or weirdo node app bullshit or custom binary doodad will have some path to trigger this thing - but the most commonly exploited scenario based on what ive seen the last few years in consulting land is gonna be shops with very lax security, shared accounts, injectable automated processing, ci/cd pipelines, and llm craps
@rootwyrm the nation states are 100% gonna go for those edge cases tho. and its gonna hit shit like fortinets and ciscos and panw and ... hey @cR0w and @da_667 and @reverseics get in here, we're back to ../ again!
-
@rootwyrm the nation states are 100% gonna go for those edge cases tho. and its gonna hit shit like fortinets and ciscos and panw and ... hey @cR0w and @da_667 and @reverseics get in here, we're back to ../ again!
@Viss @cR0w @da_667 @reverseics well yeah, I thought that was kinda obvious when I said basically anything that uses the crypto API could be exploited and www:www still has access to ../../../bin/bash
-
@Viss @cR0w @da_667 @reverseics well yeah, I thought that was kinda obvious when I said basically anything that uses the crypto API could be exploited and www:www still has access to ../../../bin/bash
@rootwyrm @cR0w @da_667 @reverseics its amusing that "firewall appliances" are going to have more surfaces exposed to exploit this thing than linux boxes
-
@rootwyrm @cR0w @da_667 @reverseics its amusing that "firewall appliances" are going to have more surfaces exposed to exploit this thing than linux boxes
@Viss @rootwyrm @da_667 @reverseics you think it's funny? joker quote
-
@Viss @rootwyrm @da_667 @reverseics you think it's funny? joker quote
-
@Viss @cR0w @rootwyrm @reverseics and I'm tired of pretending its not
-
@rootwyrm @cR0w @da_667 @reverseics its amusing that "firewall appliances" are going to have more surfaces exposed to exploit this thing than linux boxes
@Viss @rootwyrm @cR0w @da_667 @reverseics
*what*? perimeter and middleware boxen as platforms to exploite? surely not. they are *security* devices, so they must be more secure!
*choke* *gasp* *cough*
ok. couldn't get that all out with a straight face...
-
right now, every single remote code vuln that will lead to command injection or rce will make this #copyfail thing a very very big deal.
so all those qa servers and staging servers and test boxes you think nobody gives a shit about that are just flapping out there in the public, not being logged, not in the siem, not getting alerted on, not getting patched?
all those are gonna catch the "oops attackers overwrote sshd to steal creds" disease.
or cryptominers. or proxies.
@Viss just think of all the WordPress sites with RCE there where pretty useless up until now.
-
this is why ive been on a tear about architectural defensive measures, and adversarial defensive measures.
because when you build shit from the ground up to be defensively positioned at the architecture layer, this shit is way harder to exploit - purely because its way less accessible.
every k8s cluster out there right now with alpine linux rocking kernel 6.7 or whatever is kindling for this thing.
@Viss or be ready for supply chain exploits doing this to dependencies or typosquats. Then pushing that into containers. That’s the path I’m concerned about
-
@Viss or be ready for supply chain exploits doing this to dependencies or typosquats. Then pushing that into containers. That’s the path I’m concerned about
@onyxraven there are so many angles on this thing
