SoylentNews is people
SoylentNews
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: 0) by Anonymous Coward on Sunday August 20 2017, @12:04AM (1 child)
It's not possible to sanely restrict what a library can do... do you know how much overhead that would involve? a lot.
(Score: 0) by Anonymous Coward on Sunday August 20 2017, @12:58AM
Not true. In the case where you need the same library loaded, and actively in sue for two different applications with different permissions, set the library's permissions to the overlap (not union). In the event of a permission error, you can either duplicate the library in memory, or temporarily only schedule one libraries users at a time and toggle the permissions.
I expect the cases where this would cause significant overhead are rare. My phone very rarely needs to run two apps with significant CPU load or latency requirements at the same time, so in the rare case where some background app needs the library with different permissions, it can wait for a change, then get its little time with different permissions.
Also, can't most memory mapping hardware map the same physical page to two different virtual pages with different permissions? And arn't the different apps running in different processes just sharing read-only code memory? How is this even a problem?
This isn't hard. You build a secure system that follows its permissions rules, even if the overhead is high, then work on lowering the overhead. Just making stuff insecure is stupid.