What you're describing in your SneakyDev scenario is a collusion attack: 2 apps installed on a device where one app manages to raise it's privileges by delegating authority to another. You mention using SharedUserId in your example, but the attack could even be possible if SneakyClock were written by a different developer, and had an open interface that other apps can invoke without a permission (via intents or something similar).
Fortunately if the dev is using the SharedUserId feature, Android knows that all apps sharing a UID effectively share the union of all permissions assigned individually to each application. You can verify this by going into Settings -> Apps -> SneakyCal, and you would see that it has the Internet permission (inherited through SneakyClock, though that fact is not displayed). If SneakyClock was installed first, and SneakyCal second (and they were both sideloaded, not installed through the Android Market), the Android installer would show that SneakyCal requires the internet permission, even though it is not explicitly requested in the manifest. When installing apps via the Android market, permissions are read from the Manifest, and approved in a custom UI which seems to ignore the state of installed apps on the phone, so the user might be fooled into thinking an app has fewer permissions than it actually gets once installed. There is also no UI cues for displaying the fact that apps will share a UID with another app on the device. So to summarize: Can an app get privileged access to a phone resource via another app? Yes. Will the user know that this is happening? Probably not. I will say that if a user ends up installing SneakyClock (which in your example is already malicious, and has privileges), that application could just perform the malicious task on its own. It doesn't need SneakyCal. Is "the whole sandbox-shit" useful? Absolutely. It helps prevent other attacks not mentioned here. For example, you can be reasonably certain that between those 2 apps, none of them will get access to your camera or GPS. It's probably also easy to see through static analysis that SneakyClock has an open API that other apps can call. But I think the bottom line is that in general, if 2 apps are deliberately malicious and colluding on the device, it becomes very difficult to implement a system-level protection to prevent attacks. [shameless plug] - We wrote a research paper on this and related installation/sharing issues, and we discuss possible alternatives. http://www.ccsl.carleton.ca/~dbarrera/files/spsm12-barrera.pdf Cheers On Thu, Nov 8, 2012 at 4:24 AM, Hannes <[email protected]> wrote: > Hi, > > I'm not really into Android programming, but I'm a fan of privacy and > concerned about the tendency of it's disappearance. > Lately, I've been wondering how secure the Android platform is, and if a > user can feel "somewhat" safe, if he (as an example) installs an App that > claims to "not require Internet access". > Most people would assume, that in theory (all possible exploits aside), if > there is no way for the App to communicate to a network, there could be no > way that the outside world be ever able to get hold of the App's private > data (because of the SandBox). > > When I stumbled across SharedUserId, which developers can use to share > data between their own Apps, I got really puzzled. > > I mean, picture this scenario: > > Developer "SneakyDev" writes two Apps: > A Calendar-App (SneakyCal), that requires NO granted permissions at all > -and it's purpose would be obvious. > A Clock-App (SneakyClock), that only requires permission for > Internet-Access, because it's absolutely reasonable purpose would be to > fetch the time from an NTP-Server. > > Now user "PrivacyGeek" finds SneakyCal in Playstore and decides to install > it... he needs a calendar and also loves the fact that the app needs no > permissions whatsoever (that must be super-secure, even more than the > built-in one)! > Some weeks later, he is at the Playstore again and stumbles across > SneakyClock... and decides to install it, because a Clock-App that only > requires Internet-Access for contacting NTP is just reasonable and could do > no harm, because what private data could you ever store within a > non-interactive clock-App, right??!! > > > Ok... and now I'm asking myself: The user now has SneakyCal, that stores > the users private agenda in it's sandboxed app-data directory ...and > SneakyClock, with originally no sensitive data in it's folder, *BUT* has > Internet-Access *AND* has access to all of SneakyCal's data, because it was > written by the SAME DEV (who sure as hell used the SharedUserId-Feature). > > I mean, maybe I'm misunderstanding here something very badly, but it seems > like, that by installing SneakyClock, SneakyCal is ...so to speak... also > secretly granted (because it's family) all of SneakyClock's permissions.... > and the naive user has NO IDEA about it, because he HAS TO TRUST in what is > told him: That SneakyCal is plain and simple NOT PERMITTED access to the > internet in whatever way. > > My conclusion: I don't think it is a very hard task at all, to use a > directory as a "virtual-data-exchange-socket" to just pass data through for > the sole purpose of making use of permissions that were not explicitely > granted to the App. > > So my big and (quite) discomforting question is: Are Android-users LIED > DAILY into their face about the fact, that an App from the same Developer > will (effectively) automatically inhire ALL of the other CAPABILITIES of > the other installed Apps of the same developer? Please tell me I > misunderstood something *very* badly, because I cannot believe that a > security-system can be flawed so primitively-obviously and nobody > complaining about it. > > My point is, only because an app is not DIRECTLY granted API-ACCESS for > retrieving (for example) the GPS-coordinates, if it simply can ask his > "brother" (in his own "language") to pass that information, where is the > difference? The information WAS delivered! > Should my assumptions be correct, it makes me feel quite sad for how we > all are fooled. Because then, in my opinion, they could really have skipped > the whole sandbox-shit from the beginning, because it serves no other > purpose than to sell a complete illusion. > > -Hannes > > > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/android-security-discuss/-/sSV0HsBxV78J. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > -- David -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
