Arthur T Knackerbracket has found the following story:
Oxford researchers [...] (Vincent Taylor, Alastair Beresford and Ivan Martinovic) [...] [looked] at how the same library in two different apps could expose information from a higher-privilege app to one with lower privilege.
They write that this “intra-library collusion” (ILC) happens “when individual libraries obtain greater combined privileges on a device by virtue of being embedded within multiple apps, with each app having a distinct set of permissions granted”.
As the paper explains, shared libraries can borrow permissions an app doesn't have [...] That's a threat, because library re-use across different apps isn't a bug, it's a feature: it makes app development more efficient and keeps apps small by letting them use code pre-loaded to a device.
While noting that attackers are standardising their own libraries, the researchers focussed their effort on advertising libraries [...] handling location, app usage, device information, communication data like call logs and messages, access to storage (including, for example, a user's files which can indicate their interests), and the microphone.
Of more than 15,000 apps with more than a million downloads, the researchers went to work decompiling apps to identify the libraries they linked to. Those they successfully decompiled, they analysed for their intra-library collusion potential.
The 18 most popular libraries include familiar names:
Library % of apps com/facebook 11.9 com/google/android/gms/analytics 9.8 com/flurry 6.3 com/chartboost/sdk 5.9 com/unity3d 5.2 com/applovin 3.5 com/mopub 3.1 com/inmobi 3.0 com/google/ads 3.0 com/google/android/gcm 2.7 com/tapjoy 2.4 org/cocos2d 2.4 com/amazon 2.0 com/millennialmedia 1.6 org/apache/commons 1.4 com/heyzap 1.4 com/nostra13/universalimageloader 1.3 com/adobe/air 1.0 “The main catalyst that allows ILC to happen is the failure of the Android permission system to separate the privileges of libraries and their host apps”, they write, and this at least offers opportunities for an underhanded ad network to improve their data collection without seeking extra permissions from users.
[...] Digging deeper into how advertiser libraries behaved, they found on average those libraries “leak sensitive data from a device up to 2.4 times a day and that the average user has their personal data sent to 1.7 different ad servers per day”.
-- submitted from IRC
(Score: 2) by Wootery on Sunday August 20 2017, @09:13AM
If that increase in efficiency means deviating from expected behaviour, it shouldn't be done.
It's like the 'as if' rule in compilers: your compiler doesn't have to use the CPU's multiplication instruction, it just has to have the right effect, of giving the required multiplication. If this can be done faster with addition and shifting, the compiler is free to go that route instead.
Isn't this the same thing? If the libraries subsystem reduces duplication while keeping identical behaviour, that's great. If it b0rks the permissions system, though, then that means the libraries subsystem is buggy.