VB2014 paper: Attack surface analysis of the Tizen OS

Tizen is an open-source platform designed for multiple computing platforms such as smartphones, in-vehicle infotainment (IVI), smart TV, wearable devices, consumer electronics, etc. Tizen comes at a time when the threat against mobile computing is growing in tandem with the popularity of mobile devices. Compared to Android, iOS and Blackberry, Tizen offers several different options within the device structure to combat the rise in malware targeting mobile devices. This paper will examine these options and their ability to counteract malware and privacy threats.

Tizen is a combined effort of Intel and Samsung under the auspices of the Linux Foundation, LiMo Foundation.

Similar to the architectural framework used in Firefox OS [1] and Android, Tizen uses a layered environment built upon a foundation of the Linux kernel. There are three main layers: the application, the core and the kernel [2].

Figure 1. Tizen uses a layered environment built upon a foundation of the Linux kernel [2].

The Tizen application architecture can further be divided into two layers. The web framework provides support/runtime to facilitate the execution of HTML5 and JavaScript. The Native framework is composed of system services and a set of native namespaces providing open-source APIs, with which applications can be developed using C/C++ [3].

The core layer consist of the following services: application framework, base, connectivity, graphics, location, messaging, multimedia, PIM (personal information management), security, system, web and telephony.

Currently, the attack surface of the modules described above consists of bugs resulting from the consolidation of the previous platforms into Tizen, as well as introduction of new features into Tizen.

A package is a container of executable content or apps that a system can install or uninstall. Each package has a unique identifier, called the ‘PackageId’, and each app within the package has a unique global ‘AppId’ as well as an ‘AppName’. All apps in a package share resources as well as the privileges defined at the package level.

The Tizen Framework supports three types of packages: web application, native apps and hybrid apps (a mixture of native and web apps). Tizen also supports the installation of RPM packages.

Figure 2. Web application packaging [5].

Figure 3. Package content [5].

Figure 4. Web content [5].

Web application packaging is based on the W3C widget packaging specification. A web application package must conform to the following conventions:

A hybrid/native application package must conform to the following conventions:

The root of the Tizen native package is the path of the ZIP archive, which contains reserved folders.

At the core of Tizen’s security enforcement is privilege control and application signing, which includes process isolation and mandatory access control [6].

The key principles are as follows:

Tizen operates Simplified Mandatory Access Control Kernel (Smack)-based access control and process isolation. The key principles of this are as follows:

Tizen operates a secure execution environment:

<feature name="http://tizen.org/feature/network.nfc"/> 
<tizen:privilege name="http://tizen.org/privilege/application.launch"/> 

<Requirements> 
   <Feature Name="http://tizen.org/feature/camera">true</Feature> 
</Requirements> 
<Privileges> 
   <Privilege>http://tizen.org/privilege/notification</Privilege> 
</Privileges> 

3.3 Post install privacy control

An additional measure introduced in the Tizen framework allows users to install apps while denying some of the apps’ attempts to collect the user’s data – a solution to the fundamental problem with the commonly used security model of installing an app with an all-or-nothing approach.

Very similar to the feature that was dubbed ‘AppOps’ [8] in Android 4.3, Tizen allows post privacy controls, denying apps the ability access user data based on user-defined rules.

Figure 5. App ops[8] .

Figure 6. Post privacy controls.

The rules set by the privacy policy apply to all apps in a package and cannot be defined on a per-app basis.

[SubjectLabel] [ObjectLabel] [access(rwxa)] 

A growing concern regarding threats targeting smartphones is the interactions between separate applications – not just artifacts of single components – in order to carry out malicious activities [10].

In Android, IPC is largely a function of Binder. Binder is a kernel device driver that uses Linux’s shared memory feature to achieve efficient, secure communications. Firefox OS tries to isolate apps completely from direct communication – the only form of communication between apps is indirect. Tizen, on the other hand, makes extensive use of several protocols for interactions despite the fact that D-bus remains the officially recommended protocol of choice. Most of the OSS modules, such as ConnMan, use D-Bus for IPC, but other middleware – notably modules inherited from the SLP (Samsung Linux Project) – use custom forms of IPC, thus there is no definitive IPC protocol in Tizen. It is also worth mentioning that Tizen 3.0 will see the introduction of k-dbus, which will attempt to consolidate IPC across the platform.

Similar to the web framework used in Firefox OS called ‘Gecko’, the Tizen WRT supports the management of web apps (installation/uninstallation) and the execution of Tizen WebApps as well as W3C APIs and non-W3C APIs [11].

The CSF is a set of APIs/hooks that can be used to create security-related services. Developed by McAfee, these hooks were designed to be utilized by third-party security vendors to help harden the system. There are two types of scan engines that represent the ideal use case for the CSF: scan engines for data/content and site engines for URLs. Scan engines inspect content and are designed to use malware-matching patterns, as is typical of PC virus-scanning programs today. Site engines use a reputation system, in which the vendor categorizes URLs and creates block list policies by category (e.g. gambling, pornography, spyware, etc.) [12].

To ensure that any malware entering the Tizen ecosystem is immediately identified, applications submitted to the Tizen Store will be reviewed via a combination of static and dynamic analysis before they are published for public consumption.

The review process will subject the apps to a rigorous code review process: verifying their authenticity and integrity, using steps such as ensuring that requested permissions are used for the purposes stated, verifying that the use of implicit permissions is appropriate, and validating that any interfaces between privileged app content and unprivileged external content have the appropriate mitigations to prevent elevation of privilege attacks.

Similar to the Bouncer verification system used by Android [13], the Tizen app validation system uses an array of emulators to track app behaviour while attempting to simulate app usage in order to trigger/spot malicious actions.

Even though the review process can be viewed as a mix of the review processes used by the Android Security Team and the Apple App Review, the differentiator here is that the Tizen app validation process promises to deliver an assessment on an app within three days of the first submission of the app [14].

The three-day investigation period opens up the possibility of attacks where victims could be targeted post release using techniques such as ad networks with low or no security screening processes [15].

It would not be an exaggeration to say that security is a dominant factor when it comes to the architecture of Tizen. The concern for security is not only reflected in the design of the platform all through the Tizen ecosystem, as exhibited by the app validation process. But in the current threat landscape, where threats against mobile devices have peaked, discoveries of issues such as the first public vulnerability related specifically to a Tizen device [16] and risks of XSS attacks [17] targeting support for web apps means that Tizen will constantly have to keep evolving, not only at the platform level but also at the ecosystem level, to ensure that the available attack surface is always kept to a minimum. Even though the security measures taken in Tizen reflect best practices and lessons learned from the threat landscape, there are still improvements that can be made.