Earlier quoted context omitted.
Everything in this comment is wrong.
Technically yes. Practically, I disagree.
The part where you run everything as root is particularly stupid. But yes, user isolation has been weakened quite a bit.
Dirty Frag: Universal Linux LPE
51–60 of 370 posts
Re: Dirty Frag: Universal Linux LPE
#52Earlier quoted context omitted.
It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.
No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land. Some folks like the termux rebels, occasionally find out there is a sherif in town. > As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code…
That's specific libraries, when using the default linker. You could construct that same behavior on desktop linux too. And you can avoid it equally well on Android - you can statically-link things just fine, you can use libraries you actually control, and presumably use a custom linker if desired. It's utterly non-surprising that "you run code you don't control" results in "said code...can do arbitrary things for unsupported use". (Never mind that, instead of a "sherif", they could've just renamed all private symbols, or just naturally replaced them over time, breaking your code all the same, just in a more confusing way)
Also some obligatory Linux vs GNU/Linux comment. (and it's not like GNU/Linux doesn't ever change under your feet - see the glibc DT_HASH debacle)
Re: Dirty Frag: Universal Linux LPE
#53So 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.
Re: Dirty Frag: Universal Linux LPE
#54So if I understand correctly 3 modules are involved: - esp4 (kernel config "CONFIG_AF_RXRPC") - esp6 (kernel config "CONFIG_INET_ESP") - rxrpc (kernel config "CONFIG_INET6_ESP") Is this correct?
You mixed up the names vs. config options but yes killing those 3 options should make you "safe". No warranty.
Re: Dirty Frag: Universal Linux LPE
#55Earlier quoted context omitted.
It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.
No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land. Some folks like the termux rebels, occasionally find out there is a sherif in town. > As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code…
https://www.androidpolice.com/google-support-linux-kernels-a...
Google relies on Linux LTS kernels. When the Linux LTS team dropped support from 6 years down to 2 years, Google stepped in to cover the 4-year gap.
It is Linux. It's basically a distro.
Re: Dirty Frag: Universal Linux LPE
#56Linux is a single user system and should be treated as such. Run your services as root. Don't rely on unix user primitives for security.
I agree with the general sentiment. I treat anything running arbitrary machine code as if it has full access to a machine. I don't know where you get "run your services as root" from that, though. The principle of least privilege doesn't just apply to running malicious code, but running buggy code whose attack surface is exposed to evil-doers.
Re: Dirty Frag: Universal Linux LPE
#57"Because the embargo has now been broken, no patches or CVEs exist for these vulnerabilities." link: https://github.com/V4bel/dirtyfrag detailed writeup: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-... importantly: " Copy Fail was the motivation for starting this research. In particular, xfrm-ESP Page-Cache Write in the Dirty Frag vulnerability chain shares the same sink as Copy Fail. However, it is t…
"sudo" in "sudo echo 3 > /prox/sys/vm/drop_caches" does not do anything because only runs echo, not the write.
And if a machine is already exploited, it's too late to do just that. You need to rebuild the whole disk image because anything on it could be compromised.
Re: Dirty Frag: Universal Linux LPE
#58"Because the embargo has now been broken, no patches or CVEs exist for these vulnerabilities." link: https://github.com/V4bel/dirtyfrag detailed writeup: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-... importantly: " Copy Fail was the motivation for starting this research. In particular, xfrm-ESP Page-Cache Write in the Dirty Frag vulnerability chain shares the same sink as Copy Fail. However, it is t…
"sudo" in "sudo echo 3 > /prox/sys/vm/drop_caches" does not do anything because only runs echo, not the write. And if a machine is already exploited, it's too late to do just that. You need to rebuild the whole disk image because anything on it could be compromised.
>And if a machine is already exploited, it's too late to do just that. You need to rebuild the whole disk image because anything on it could be compromised.
this is more targeted at the people who run the PoC to see if their machine is vulnerable.
just transcribing some relevant stuff from https://github.com/V4bel/dirtyfrag/issues/1 so that people visiting this thread dont need to poke around a bunch of different places.
Re: Dirty Frag: Universal Linux LPE
#59Earlier quoted context omitted.
7 days from disclosure to publishing a how-to guide to get root to the entire planet doesn't scream "responsible" disclosure to me.
Its not the reporter's fault that other people broke the embargo.
They don't have to publish a working exploit as soon as the embargo is broken, though.
Re: Dirty Frag: Universal Linux LPE
#60This 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…
I don't follow. LLMs spotted these bugs in the first place . You seem to be saying that these discoveries are indications that they're bad for vulnerability discovery.
I don't think the copy.fail people understood the issue they found, as is evident by the heavy focus on AF_ALG/aead_algif, which is essentially "innocent" as we're seeing here.
I think LLMs are great for vulnerability discovery, but you need to not skimp on the legwork and understanding what even you just found there.