Nothing surprising there, even if 50 issues will be found in a month, since there exists more advanced relativity-based automation features as LLM.
It's easier to attack a solution with its source code available, and with an LLM trained on existing vulnerabilities found, and some datacenters/funding available, et voila, you have a system set to reveal flaws in already awesome projects, to be fixed.
This is normal. You just need power, and time. And there must be more found but left undisclosed, for better times, strategic 0days etc.
Who has such power, and funding? Is it possible Linux competitors do pay enthusiasts to attack, reveal, and damage reputation? What if someone who has funding and time, would try attacking their closed source code instead? Regardless, I wish them safety and peace, too.
This means Linux is getting better faster than alternatives :) With many eyes, all bugs are shallow, and now there are nearly infinite AEyes looking at the source code. In a year, Linux will be the most bulletproof operating system ever.
> the attacker does not need to break in remotely. The danger is that once an attacker gets in — through a vulnerable WordPress plugin, a web shell, weak SSH credentials, or a compromised container
This part I don't understand. Wouldn't the attacker need to break in remotely? Ö
"through a vulnerable WordPress plugin, a web shell, weak SSH credentials, or a compromised container"
DirtyFrag alone doesn't help an attacker; they need to get in first. But the blast radius is much wider now. A simple wordpress flaw, or a prompt injection in your OpenClaw skills, or a supply chain compromise in npm librarires means you are now root in that system.
Your understanding is fine. In many environments, you can still do a lot of damage just by popping a shell and being able to access the database/sensitive environment variables/sensitive code. Getting to root would just be the icing on the cake.
That being said, it's pretty common for non-containerized processes to drop permissions to a low-privileged service account (like nginx running as `nobody`), so it definitely thwarts defense-in-depth in those setups.
In containerized environments, my understanding is their use of namespaces means you still need something more clever than just "patch out the authentication logic in su via the page cache" to escalate permissions in the system to break out of the container. That doesn't mean it's impossible in these exploits (the original copyfail writeup alluded to a second writeup coming to this effect - distinct from dirtyfrag though), but it does mean you're not going to be able to just spam the PoCs floating around.
Also, meant to share some interesting readings. In the Kubernetes world, my RSS feed lit up with their blog post about user namespaces being generally available in k8s 1.36.
They actually provided some example CVEs that wouldn't have been possible if in addition to containers, they were also using user namespaces https://github.com/kubernetes/enhancements/tree/217d790720c5.... The first example talks about "CVE-2019-5736: Host runc binary can be overwritten from container. Completely mitigated with userns." So it seems like getting root in a regular container gives you more of an attack surface, but if user namespaces are deployed, then it's even harder to do anything useful with it. I am looking forward to the aforementioned writeups since user namespace escapes usually mean another kernel bug.
Slop blogspam summary. Even before everyone lost their mind to Mythos and other IPO bait, local privilege escalations in Linux were a dime a dozen (not always as universally exploitable, but plenty).
Previously covered at https://news.ycombinator.com/item?id=48053623
Time to port everything to RedoxOS? =)
Nothing surprising there, even if 50 issues will be found in a month, since there exists more advanced relativity-based automation features as LLM.
It's easier to attack a solution with its source code available, and with an LLM trained on existing vulnerabilities found, and some datacenters/funding available, et voila, you have a system set to reveal flaws in already awesome projects, to be fixed.
This is normal. You just need power, and time. And there must be more found but left undisclosed, for better times, strategic 0days etc.
Who has such power, and funding? Is it possible Linux competitors do pay enthusiasts to attack, reveal, and damage reputation? What if someone who has funding and time, would try attacking their closed source code instead? Regardless, I wish them safety and peace, too.
Are you suggesting somehow Microsoft or Apple would be doing this? That seems pretty perverted if you are.
If I were Redhat or any other distro maintainers, this seems like something I'd want to be doing internally to lock it down.
This means Linux is getting better faster than alternatives :) With many eyes, all bugs are shallow, and now there are nearly infinite AEyes looking at the source code. In a year, Linux will be the most bulletproof operating system ever.
> the attacker does not need to break in remotely. The danger is that once an attacker gets in — through a vulnerable WordPress plugin, a web shell, weak SSH credentials, or a compromised container
This part I don't understand. Wouldn't the attacker need to break in remotely? Ö
The answer is in your question:
"through a vulnerable WordPress plugin, a web shell, weak SSH credentials, or a compromised container"
DirtyFrag alone doesn't help an attacker; they need to get in first. But the blast radius is much wider now. A simple wordpress flaw, or a prompt injection in your OpenClaw skills, or a supply chain compromise in npm librarires means you are now root in that system.
Your understanding is fine. In many environments, you can still do a lot of damage just by popping a shell and being able to access the database/sensitive environment variables/sensitive code. Getting to root would just be the icing on the cake.
That being said, it's pretty common for non-containerized processes to drop permissions to a low-privileged service account (like nginx running as `nobody`), so it definitely thwarts defense-in-depth in those setups.
In containerized environments, my understanding is their use of namespaces means you still need something more clever than just "patch out the authentication logic in su via the page cache" to escalate permissions in the system to break out of the container. That doesn't mean it's impossible in these exploits (the original copyfail writeup alluded to a second writeup coming to this effect - distinct from dirtyfrag though), but it does mean you're not going to be able to just spam the PoCs floating around.
Also, meant to share some interesting readings. In the Kubernetes world, my RSS feed lit up with their blog post about user namespaces being generally available in k8s 1.36.
They actually provided some example CVEs that wouldn't have been possible if in addition to containers, they were also using user namespaces https://github.com/kubernetes/enhancements/tree/217d790720c5.... The first example talks about "CVE-2019-5736: Host runc binary can be overwritten from container. Completely mitigated with userns." So it seems like getting root in a regular container gives you more of an attack surface, but if user namespaces are deployed, then it's even harder to do anything useful with it. I am looking forward to the aforementioned writeups since user namespace escapes usually mean another kernel bug.
This does sound inadequate. Do you think it's a possible AI slop "logic" written, too?
Slop blogspam summary. Even before everyone lost their mind to Mythos and other IPO bait, local privilege escalations in Linux were a dime a dozen (not always as universally exploitable, but plenty).