|
| ▲ | sgjohnson 6 hours ago | parent | next [-] |
| Not true, if there’s any evidence of the exploit being used in the wild, it’s much more responsible to release immediately. Considering that the patches have been available for a while, someone surely reversed what they were for and was actually exploiting this in the wild. In the age of AI, I’d argue that “responsible disclosure” is dead. Arguably even in closed source projects. Just ask Claude to do a diff between the previous version and to see whether anything fixed in there could have had security implications. We’re not there yet, but very soon the only way to responsibly disclose a vulnerability will be immediately. |
| |
| ▲ | ori_b 6 hours ago | parent [-] | | But they didn't release immediately -- they waited a month, but forgot to tell the distros, and forgot to check if waiting a month had actually lead to distros picking up the patches and shipping them. |
|
|
| ▲ | semiquaver 6 hours ago | parent | prev | next [-] |
| “Made it into the wild?” Patches landed a month ago. Should they also wait until my linksys router from 2018 has a patch ready? |
| |
| ▲ | ori_b 6 hours ago | parent | next [-] | | Patches are still in the process of landing in most major distros as of the time of this writing. Most users are not able to get an update through their distro's packaging mechanisms. | |
| ▲ | SoftTalker 6 hours ago | parent | prev [-] | | It's a local vulnerability at least. How many people do you let log in to your router? With the way linux is used these days, I'd guess the number of systems with untrusted local users is pretty limited. Even with shared hosting, you generally have root in your VM or container anyway. Unless this enables an escape from that? Still the risk that people who run "curl | bash" without care could get bitten, but usually its "curl | sudo bash" anyway... | | |
| ▲ | sgbeal 6 hours ago | parent | next [-] | | > Even with shared hosting, you generally have root in your VM or container Lots of shared hosters don't use VMs or containers. It's some arbitrary number of people logging in to a shared system, each one with a home directory under /home/THE_USER_NAME. i've had several such hosters over the years (thankfully not right now, though). | |
| ▲ | sjpb 5 hours ago | parent | prev | next [-] | | > With the way linux is used these days, I'd guess the number of systems with untrusted local users is pretty limited Things like HPC clusters are multiuser & don't entirely trust their users. If they did we wouldn't need users/groups/permissions etc in the first place. | | |
| ▲ | cozzyd 3 hours ago | parent [-] | | Yes. Not even just HPC clusters, shared login servers are pretty common in academia. I manage several in our lab. Sure, we mostly trust the users against malice more or less but not so much against incompetence. A malicious vscode plugin would run rampant in this space. And then there are users running claude-cli and friends who may just find it convenient to use a local root exploit to remove obstacles. |
| |
| ▲ | dist-epoch 6 hours ago | parent | prev | next [-] | | With this exploit it's trivial to jump from one container to another neighbor container. I've tried it and succeeded. So containers don't protect you, only a VM. | | |
| ▲ | SoftTalker 6 hours ago | parent [-] | | So anyone pulling a malicious dockerfile jeopardizes the host? That would be bad... | | |
| ▲ | ori_b 3 hours ago | parent [-] | | ...no shit? Why do you think people care about this issue? |
|
| |
| ▲ | michaelmrose 6 hours ago | parent | prev [-] | | Local root is part of the path to escaping |
|
|
|
| ▲ | staticassertion 3 hours ago | parent | prev | next [-] |
| That's mostly on Greg, a bit on the author. |
|
| ▲ | GrayShade 6 hours ago | parent | prev [-] |
| Fedora is patched. |
