Static security analysis of Tizen apps

At the 2014 Tizen Developer Conference (TDC) in San Francisco, Dan Wallach of Rice University delivered a presentation about his ongoing work to perform security analysis of third-party apps written for Tizen mobile devices. While static analysis can never catch every violation of security rules, a framework that helps automate the process would simplify any "app store" review process, as well as providing side benefits to the app and platform developers.

Wallach's research is partly funded by Samsung, he disclosed at the beginning of his talk, but his presentation in no way indicates that he speaks on the company's behalf. Wallach works at Rice's Computer Security Lab, and co-leads a team of researchers and PhD students on this project. The target is performing automated, static analysis of mobile Tizen apps submitted to the app store, in order to reduce the amount of time that each app demands of a human reviewer.

Analysis of Tizen apps

Wallach's team is only investigating one piece of the app review process, of course. Tizen offers two development frameworks: HTML5/JavaScript and native code; Wallach's team is looking at native apps while someone else is doing similar work on analysis of HTML5 apps. But Tizen apps can also be compiled with either a GCC or LLVM toolchain; Wallach's team is focusing on analysis of the LLVM-generated apps.

The reason is that the LLVM toolchain produces cross-platform LLVM "bitcode" executables (which are intended to run on either Intel or ARM hardware, both architectures that are supported by Tizen). The LLVM bitcode is an intermediate representation of the compiled program, designed to be optimized, he said, but that also means it is ripe for other forms of analysis. It preserves the high-level semantics of the program, unlike machine code, and it can be generated from multiple languages (unlike Java bytecode). Finally, it supports multiple architectures (which is of particular interest to the Tizen project), so one analysis framework would assist a lot of developers.

The security analysis performed by the team is static, he explained, meaning that the submitted app is not executed. Instead, the framework examines the program structure, flagging potential security problems. The basic idea is to mark points where app security is "tainted;" for example, in a potential information leak, such a point would have both a "source" call (e.g., requesting the device's GPS location) and a "sink" (e.g., sending some data to a remote server).

Obviously, if there is no conditional branching in the program flow between the source and the sink, it is trivial to determine if the program copies the GPS location into the data structure sent to the remote server, which could be a violation of security policy. Static analysis has to cope with the conditional flows, Wallach said. Historically, static analysis has been a conservative approach: assuming all branches in the code are taken, which can lead to false positives. It must also deal with other complexities such as pointer aliasing and object-oriented method dispatching, both of which introduce a lot of unknowns to cope with. On the other hand, he said, the opposite approach—dynamic analysis—tends to produce false negatives.

Control-flow analysis is not a new problem, of course, and there are existing approaches to reducing the potentially overwhelming number of false positives. The techniques do require some knowledge of the platform: knowing what the most likely vulnerabilities are, knowing what special cases should be allowed, and so on.

The group at Rice has been working for the past year to build an LLVM information-flow analysis engine for Tizen, though the project is far from finished. As of now, the group's work can statically analyze LLVM-bitcode Tizen apps, although Wallach pointed out that it does not analyze the Tizen libraries or kernel for vulnerabilities. Samsung provided the team with 30 apps as test cases, and the analysis found only one privacy leak, but just as importantly, it produced no false positives or false negatives. 30 apps (and 30 known apps, for that matter) is not a large test set, of course; an audience member asked Wallach if he would be interested in working on his company's library of 300 apps, to which Wallach replied "that would be fantastic."

The framework that the team is developing is intended to fit into the Tizen app-store submission process, so that new submissions are analyzed and a report is generated for a human analyst to look over. Security problems caught would send the app back to the developer for further work, but could also be used to help the Tizen project refine its security policies. Wallach noted that this approach differs from both Apple's app store review process and Google's; Apple's is secretive but apparently labor-intensive and slow, while Google's is known to be 100% automated and fast, but allows problematic apps to slip through.

What's next

The next stage of the ongoing research, Wallach said, is to perform similar analysis of the Tizen libraries. Everyone likes to think about their platform APIs as being discrete, orthogonal entities, he said—Bluetooth, Networking, Filesystem, etc.—each of which mediates access to some specific kernel-level feature. But in reality, they overlap quite a bit and share access to the same resources. In many cases they are interdependent, too.

That makes it difficult to construct strict security policies, as Tizen would like to do. For example, he described a well-known 1996-era Java vulnerability. The URL handler was intended to let an application retrieve a remote URL, but the URL-handling code also understood other protocol schemes like file:, which created a vulnerability. But simply blacklisting file: was not sufficient, since applications should be allowed to create and retrieve temporary files (for caching and so on).

The group's plan is to perform its static analysis on the Tizen libraries to map all of the platform APIs to kernel calls, then use that mapping to verify (and update) Tizen's Smack security policies. But the analysis will have other benefits, too. It can be adapted into the Tizen build process, so that any changes to the libraries that have security-policy implications can be flagged automatically. It will also allow higher-level APIs to be written while forbidding direct calls to lower-level dependencies.

Subsequently, the group may also annotate code with #pragma statements to denote exceptions to the security policy that a human auditor has determined is safe. The example he gave was an app doing a filesystem read to a cache file that it owns; an auditor can mark this with

    #pragma SecurityAudited(OpenFile)

and eliminate a false-positive result in the automated analysis step. The group also intends to perform an information-flow analysis of the entire Tizen library set, and to analyze Tizen's multiple inter-process communication (IPC) mechanisms. When he was first approached about working with Tizen, Wallach recalled, he asked "what's your IPC mechanism?" and was a bit surprised at the answer: "which one?" Comparable work in Android, he noted, has uncovered and fixed many security holes.

Eventually, he concluded, as the Tizen app ecosystem grows, the "known bad behavior" patterns will emerge, and analysis can focus more directly on them. In the meantime, static analysis frameworks like his team is developing will help reduce the pressure put on Tizen's Smack policy maintainers (by consolidating and simplifying rules), and will help developers write safer apps. It may even be possible, he said, to eliminate the need to manually write app "manifest" files (which list the permissions that an app requires); if the analyzer can determine which privileges the app actually uses, that is better than a list of what it claims it needs.

There is always a risk that making the security analysis process public will have the side effect of showing app developers "what they can get away with," he admitted, but that trade-off is one that the project and app-store maintainers will have to make. Wallach's group has also not yet made its code available to the public; for the project to have a significant impact on Tizen (rather than just on Samsung's app store), such a release will, no doubt, eventually be needed by the rest of the community.

[The author would like to thank the Tizen Association for travel assistance to attend TDC 2014.]