Was discussing this with folks last night - I think it's a relatively overlooked aspect of this report citizenlab.ca/2019/09/poison - No sandbox escaping used/wanted - just exploit the webview and persist in heavily permissioned apps, utilize their granted perms
Conversation
Yeah allowing side-loading of JAR/DEX and DSO is traditionally abused by malware/spyware. Notice that all .so paths ara data assets and not apk assets. Hopefully Google will restrict it soon as announced with DexClassLoader improvements.
1
2
2
That's definitely a way to try and close it, but I'm unsure it's the best approach. Personally, I think this just speaks to the over permissioning of bloated apps. Somehow sandboxing the webview outside of an APK would also be an interest approach to reduce this attack surface
1
2
2
The renderer runs in a sandbox but apps can grant the web content access to files. In the past, GrapheneOS has disabled the ability to execute executables and libraries from app data with an exception system and Android is moving towards that without having exceptions upstream.
1
If apps package their libraries properly they get mapped directly from the apk (modern way, which minimizes storage usage and offers the best security for verified boot / attestation) or extracted by the package manager with the app unable to write to it (apk data, not app data).
"if apps package their libraries properly" < if Facebook did things properly there would be a lot less hacky work arounds in AOSP 😂
1
1
So true. Let’s also not forget that Google is doing similar hacks with Play Services (see droidguard & safetynet jars). Hopefully there will be an end to this soon.
1
1
Show replies