Just in time, we have a great announcement:
Today at 11 am (GMT-5), Jie Huang will present our work on compartmentalizing advertisement libraries in arbitrary third-party Android apps in the Securing Mobile Apps session at the ACM Computer and Communications Security Conference (CCS’17). This is an important step, because it is the first paper appearing on a top tier conference that makes heavy use of ARTist’s instrumentation capabilities.

You can have a look at the paper here, but let me give you a quick introduction as well.

The main problem we want to solve is the following: Apps and their libraries share the same UID and they often run in the same process. While from a security perspective, they should be deemed as two distinct security principals, in reality the library has access to all the app’s files and permissions due to the fact that enforcement is mostly based on the app UID. There have been proposals in academia to solve this problem, mostly by introducing changes on the Android OS to either split apps up and put a trusted security boundary in between or to have advertisement libraries as different entities organized by an advertisement service in the first place (cf. AFrame, AdDroid, AdSplit, FlexDroid, …). However, all those approaches suffer from the fact that you need to deploy a custom Android ROM to utilize those changes or even need the assistance of the app developer. If you would, however, use Inline Reference Monitoring or other intra-app solutions (cf. NativeGuard, PEDAL, … ), you often lose security guarantees, because in its own process the library can circumvent this, and/or you break the app signature, which renders shared UIDs and updates impossible.

Enter ARTist and its capabilities to instrument apps without breaking the app signature or modifying the OS. For the CompARTist paper, we achieved the best out of both worlds by using the ARTist instrumentation framework to split an application into two distinct apps, one for the main developer’s logic and the second one for the advertisement library. Having the library running under a distinct UID, it does not have access to the app’s files and we can control it’s permissions independently. The main challenge now was to reconnect the broken communication between the app and the ad lib. This was achieved throguh a so-called Binder IPC-based communication protocol, where instead of calling a method directly on an ad lib object, we would use a proxy that signals the ad process to invoke the call on the library side and send the required parameters along. Effectively, we created a novel remote procedure call (RPC) protocol via Binder IPC. For callbacks, the same scheme applies reversely. So where does ARTist come into play? We used ARTist to transform each single interaction between application and library to this novel RPC mechanism. While there were a lot of interesting technical challenges to solve, I will leave the details for the paper. It is worth noting that, in contrast to the rather minimalistic proof-of-concept ARTist modules that are included in the code as examples, this module is a completely different thing. It scans for particular instructions and not only adds but replaces whole code sequences.

I will update this post later with some figures so it is easier to follow, but in the meantime, if you happen to be at CCS’17 in Dallas, join us today at 11 am in the Securing Mobile Apps Session (2E) in room A2. In either case, if you are interested in our research and want to hear more or just leave feedback, either drop me (oliver.schranz@cispa.saarland) or Jie (jie.huang@mail-infsec.cs.uni-saarland.de) an email.