Greetz from academe: No place to Hyde

The beginning of a new year brings with it a bit of a lull in academic conferences. Control over academics’ lives tends to be Kidnapped by the unrelenting schedule of the school semester, and as a result many conferences occur in the summer, when teaching demands are fewer. These academic doldrums present a problem for me, in that there’s relatively little new work to write about. So this month, I’ll take another dip in the suspiciously warm waters of USENIX Security, a veritable Treasure Island of interesting research. Having now exhausted my complete set of Robert Louis Stevenson references, I turn to the strange case of ‘Jekyll on iOS: When benign apps become evil’ [1].

Spoiler alert: the premise of the paper is that malicious apps can be slipped past Apple’s app review process. The last sentence was written with dollops of sarcasm, because it’s really not much of a surprise at all. Back in 1936, Turing tackled the ever-vexing Entscheidungsproblem [2] – a term to work into casual conversation if ever there was one – and proved that what came to be called the Halting problem is in fact undecidable. Skipping forward a bit, Fred Cohen added his own undecidability results, proving that it’s not generally possible to detect viruses by their appearance or behaviour [3]. So when Apple or anyone else announces that they’ll be sifting out bad software from good, it’s essentially guaranteed to be a fool’s errand. But it’s not like anyone’s going to base a multi-billion-dollar industry on this premise. I mean, get real.

The question is thus more how malicious apps can be slipped past Apple, rather than if they can be slipped past. Therein lies the clever part. Normally, an evil-doer takes one of two approaches: create an overtly malicious app, or find bugs in an existing benign app to exploit. Jekyll attackers lean towards the latter approach, but where they control both sides of the equation. In other words, a ‘Jekyll app’ is created by an attacker, is a legitimate app (hence will pass Apple’s app review), but is also flawed and exploitable in known ways. Once the app arrives in the App Store and makes its way onto people’s devices, it can easily be repurposed for less than noble tasks. Depending on iOS version, the Jekyll proof of concept detailed in [1] was able to tweet, email, text, dial, take videos, toggle Bluetooth, and exploit the kernel and other apps.

The mechanism for a Jekyll app’s transformation is the potion of return-oriented programming (ROP) [4]. ROP gadgets, later to be strung together, are embedded purposely into the Jekyll app in a hard-to-detect fashion, along with a buffer overflow vulnerability that can be exploited to inject the ROP code. Conceptually simple, but the devil is in the detail, and the paper does not shy away from details, explaining how the researchers bypassed ASLR and performed iOS analysis to find private, but oh-so-useful APIs.

One nice feature of the Jekyll paper is that it does a good job of summarizing scattered work on the security architecture of iOS and how it can be circumvented. The authors draw on references from academic sources, but also Hack in the Box, ProCon, Black Hat, SyScan, POC and WrathofCon – an impressive list even when you consider that I made two of the names up myself. They also did a commendable job of ensuring that their work was carried out responsibly, an important point since their app had to exist at least temporarily in the App Store, where anyone potentially could have downloaded it. The researchers pulled their Jekyll app once they had downloaded it from the App Store, verifying that no one else had downloaded it, and disclosed the attack to Apple months before their paper was published.

Interestingly, Stevenson describes Jekyll as ‘the noted professor’ in his story [5], and he must have been an odd academic indeed; the only potion in my cup is the coffee that transforms me from Hyde into Jekyll.