5 ms·

> Facebook Messenger downloads these libraries dynamically as opposed to including them in the APK, so it is difficult to identify the version I examined, but i

> Facebook Messenger downloads these libraries dynamically as opposed to including them in the APK, so it is difficult to identify the version I examined, but it was downloaded on June 22, 2020. This right here, is something that scares me. I wonder if this would fly on Apple's AppStore for example. Because there's virtually no way to attest to the application's binaries (for example for forensic purposes), and it can easily be used to backdoor the app on the fly.

petedoyle 6y ago
They might be using App Bundles dynamic delivery [1] on Android, in which case this isn't really an issue. Helps keep the initial download size small, while allowing larger features to be delivered on-demand. https://developer.android.com/guide/app-bundle/dynamic-delivery https://developer.android.com/guide/app-bundle/dynamic-deliv...
abhayb 6y ago
Some amount of post-install runtime loading is basically necessary on Android if you're using shared native libs. Can't remember off the top of my head what needs to happen but basically every app runs into strange crashes until they start packaging their .so as a resource and then loading it in Application.onCreate. Chrome does this so it's at least de facto allowed. Google has to allow dynamic loading at app start because of this. Or fix whatever subtle interaction between Android and an OEM's "improvements" is causing this. Not a huge step from here to getting your library from the internet instead of bundled with the app. Not trying to justify any one app's behavior, just bringing up a fundamental reality baked into what you're saying: Apple doesn't have to deal with the gaps in its security model becoming load bearing features.
- vlovich123 6y ago
  I don't follow. Google could lock this down if they wanted to. They own System.loadLibrary, dlopen, and the kernel. If they wanted to enforce that native libraries were covered by the same signature as signed the APK they could. Maybe not now that the horse has bolted.

petedoyle 6y ago

They might be using App Bundles dynamic delivery [1] on Android, in which case this isn't really an issue. Helps keep the initial download size small, while allowing larger features to be delivered on-demand. https://developer.android.com/guide/app-bundle/dynamic-delivery https://developer.android.com/guide/app-bundle/dynamic-deliv...

abhayb 6y ago

Some amount of post-install runtime loading is basically necessary on Android if you're using shared native libs. Can't remember off the top of my head what needs to happen but basically every app runs into strange crashes until they start packaging their .so as a resource and then loading it in Application.onCreate. Chrome does this so it's at least de facto allowed. Google has to allow dynamic loading at app start because of this. Or fix whatever subtle interaction between Android and an OEM's "improvements" is causing this. Not a huge step from here to getting your library from the internet instead of bundled with the app. Not trying to justify any one app's behavior, just bringing up a fundamental reality baked into what you're saying: Apple doesn't have to deal with the gaps in its security model becoming load bearing features.

vlovich123 6y ago
I don't follow. Google could lock this down if they wanted to. They own System.loadLibrary, dlopen, and the kernel. If they wanted to enforce that native libraries were covered by the same signature as signed the APK they could. Maybe not now that the horse has bolted.