Sneaky devs could abuse shared libraries to slurp smartphone data
Privilege escalation is baked in to mobile OSes, if you look for it
Oxford researchers reckon they've spotted the next emerging trend in Android advertising (and possibly malware): using common libraries to “collude” between apps with different privilege levels.
Libraries are a common enough vector for attackers to target, but the trio of boffins (Vincent Taylor, Alastair Beresford and Ivan Martinovic) point out most research looks at apps in isolation.
So they took a different approach, looking 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 Click to embiggen
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, since these are almost ubiquitous in the world of smartphone apps, and are already collecting and aggregating sensitive personal data.
Their research focussed on 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.
They note that in such scenarios, app developers have a strong incentive to not support library privilege separation, since “it may impact their profits negatively”.
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”.
While the focus of the paper is on how advertisers might exploit ILC, it clearly offers an attack vector, especially on jailbroken or rooted phones. There's already evidence in previous studies that as many as 7 percent of apps from the Play Store contain potentially malicious libraries, suggesting that “attackers have turned their attention to libraries as a means of malware propagation”. ®