#copyfail
-
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
-
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
it this exact flavor of bullshit that i worry about whenever someone tries to convince me that keeping a password vault in the cloud is ok.
how soon does your vendor patch?
do they even know?
will they even patch? do they care?because you have given that control surface to them, and they have protected themselves from you by way of using contract language
-
it this exact flavor of bullshit that i worry about whenever someone tries to convince me that keeping a password vault in the cloud is ok.
how soon does your vendor patch?
do they even know?
will they even patch? do they care?because you have given that control surface to them, and they have protected themselves from you by way of using contract language
this is the cost of convenience today in 2026
-
this is the cost of convenience today in 2026
"but viiihiihiiiiiiss... i dont waaaaaaannuh sysadmin"
okay, cool, i hope your vest has plates in it and your helmet is on tight
-
"but viiihiihiiiiiiss... i dont waaaaaaannuh sysadmin"
okay, cool, i hope your vest has plates in it and your helmet is on tight
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.
-
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.
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.
-
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.
having the architecture component sorted ahead of time means this problem goes from a "oh fuck oh fuck oh fuck get everyone out of bed" problem to a "okay, make sure the logging is solid, lets add some detection rules, and lets make sure the patches get inserted the second they land" flavor of issue
-
having the architecture component sorted ahead of time means this problem goes from a "oh fuck oh fuck oh fuck get everyone out of bed" problem to a "okay, make sure the logging is solid, lets add some detection rules, and lets make sure the patches get inserted the second they land" flavor of issue
yes, i can help,
phobos has your back, remember?
-
@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
