Earlier quoted context omitted.
Don't disagree, but there are eBPF mitigations that work as alternatives to unloading kernel modules.
Can you elaborate on that?
Have a look at https://github.com/atgreen/rhel-block-copyfail
Dirty Frag: Universal Linux LPE
291–300 of 370 posts
Re: Dirty Frag: Universal Linux LPE
#292So umm... should I rush home and turn off all my computers?
Are they already vulnerable to RCE as an unprivileged user? Hopefully not. An LPE only allows an attacker who can already execute code on the system to become root. So, bad, yes, but it doesn't mean you are immediately pwned.
And for a single user desktop, an LPE is almost meaningless as all the really important files are in $HOME and accessible without root.
Re: Dirty Frag: Universal Linux LPE
#293Imagine how many undiscovered bugs and exploits exist in Windows.
Noone has the time given how many windows bugs are already open and active long term.
Re: Dirty Frag: Universal Linux LPE
#294[dead]
Re: Dirty Frag: Universal Linux LPE
#295Testing the rxrpc vuln on aarch64, I get a kernel data abort, which is interesting. Not looked into the root cause yet!
Huh why is this getting downvoted?
Re: Dirty Frag: Universal Linux LPE
#296Earlier quoted context omitted.
I haven't updated mine. I have a firewall and it's not exposed to the Internet. Need a key to SSH in. Same with my public facing server. Almost none of these exploits are "drop everything now and patch" unless you are somehow exposing yourself stupidly.
If you’re running any sort of CI you’re probably going to have a bad couple of days if everything goes well
To be honest, CI has always been a massive risk, I'm a bit miffed at how blasé some people are about providing runners.
Re: Dirty Frag: Universal Linux LPE
#297Earlier quoted context omitted.
>if 40% of all Android devices don‘t get a security patch No system will stay secure once it does not receive updates. That does not exclude it from being more secure than another system based on security feature merits as long as it does get updated. >Hardening is one part of security, patchability another. Android lacks in the latter. That is not an inherent flaw with android but OEM devices shipping modified andro…
It is an inherent flaw of android. Imagine no Windows update because Lenovo stopped support for 4 year old notebooks
It's 7 years because there limiting factor is hardware firmware support. A lot of desktop hardware does not receive firmware updates above 4 years either but that just gets shrugged off like you do because "OS still gets updates so it means it's secure".
Re: Dirty Frag: Universal Linux LPE
#298This is very similar in root cause and exploitation to Copy Fail. Which illustrates pretty well something that's lost when relying heavily on LLMs to do work for you: exploration. I find that doing vulnerability research using AI really hinders my creativity. When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby. It's like a genie - you get exactly what yo…
> When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby. Very much aligns with my experience. For me this is the most unsatisfying thing about AI-based workflows in general, they miss stuff humans would never miss. All the time I wonder what am I missing that's right nearby? It's remarkable how many times I have to ask Claude code to fully ingest something…
It’s interesting to compare how the agentic search performs, with these targeted reads and lots of tool calls in the stream, versus the older but still valid paradigm of using a high-reasoning model like GPT-X-pro and feeding in all the relevant files at once with no tools.
I have found that the “pro” approach is much more holistic and able to tackle rather “creative” problems that require very careful design and the overall artifact is tight and self-consistent. — Claude Code by comparison is incredible in exploration and targeted implementation but indeed is not great at seeing the forest.
Re: Dirty Frag: Universal Linux LPE
#299I'm not a security expert, but I'm responsible for some (relatively low-stakes) production systems. It sounds like these two most recent exploits depend on unprivileged user namespaces, and that in fact a high percentage of LPE exploits need this feature. I use rootless containers on a couple of systems (like my dev machine server), but on most of my systems I don't, so it sounds like disabling that would be a good s…
You don't need unprivileged user namespaces for this one if you're in a position to get the target kernel module loaded. But yeah, user namespaces are basically the single most significant privesc path in the kernel, maybe io-uring is second. Disabling both (or very carefully deciding what can use them) is one of the best ways to reduce your attack surface.
I don't have any guides but you can determine which kernel modules are already loaded in your system and then just compile those in and block module loading.
Otherwise, shove everything into a container, ideally gvisor, and you've reduced attack surface by a large chunk again via seccomp.