Security-enabled Middleware for Android on Odroid

Transcription

1 University of Passau Chair for IT-Security Security-enabled Middleware for Android on Odroid Bachelor Thesis Author: Christoph Frädrich Matriculation. No.: Tutor and idea: Tobias Marktscheffel Daniel Schreckling Supervisor: Prof. Dr. rer.nat. Joachim Posegga

2

3 Abstract One step towards making the Internet of Things more secure is to provide a common platform for IoT devices. Android is a promising candidate for this as it has already received a lot of attention of security researchers and there have also been efforts to use Android on embedded devices. For Android to succeed in IoT it is crucial to verify that it is possible to incorporate security enhancing frameworks and make extensive modifications to provide additional functionality, not only with new applications but also with new hardware. In this work we investigate the possibilities of integrating new hardware types and dynamic taint analysis frameworks into the Android stack. A coherent set of system components is implemented to generically access sensors and actuators connected via GPIO. This includes a HAL module to access the new hardware type, a system service to propagate the data in the system and an Android app to test the components.

4 Contents 1 Introduction 1 2 Background Android Android specific kernel changes Hardware Abstraction Layer Libraries Runtime Components System Services Java API Framework System Startup Dynamic Taint Analysis Implementation Conceptual Approach System Service IGenGpioService GenGpioManager GenGpioService HAL Module TaintDroid Difficulties during the implementation Summary Integration into the Android stack Evaluation Component interaction behavior Android Test Applications Future Work 21 6 Related Work 23 7 Conclusion 24 Appendices 25 A File tree for the system service 26 iv

5 B File tree for the HAL module 27 C GenGpioService 28 D Onload.cpp 32 E Build Instructions 34

6

7 Chapter 1 Introduction Over the last years, the Internet of Things (IoT) has evolved from a buzzword in the media to a technology that is on the road of becoming ubiquitous[10]. A common motif in media coverage on IoT is the low security, misimplementation and misuse of IoT software and products. One of the most recent headlines was that more than 8000 IP-addresses and 1700 login details of IoT devices were leaked on pastebin[20]. Even though there are movements that lobby for more awareness, both in use and design of IoT products, the number of pitfalls in just writing software for IoT devices is still enormous. This is partly due to the lack of well-established software frameworks and platforms which work well in the context of IoT. One platform that can be called well-established in its current area of use is Android. It is the most used Smartphone operating system and[11] has extensive guidelines for creating new apps[15] and a thriving ecosystem which provides users with millions of apps[17]. These are great advantages of a platform that could become the standard in a field. However, regarding IoT, other qualities are needed as well. The first stumbling block is the limited information on the internals of the Android stack. The second quality we feel is unclear is how easily Android can be extended with new hardware such as sensors and actuators. Both qualities can be seen as the reason why there is only a limited amount of work related to extending Android with new components. Additionally the protection of users from malicious applications that could misuse information from sensors or actuators needs to be improved[9]. Extending Android by new hardware, especially by hardware types that are uncommon for Android devices such as sensors connected via GPIO, requires not only knowledge of the new hardware but also of the Android stack as a whole. Even though Android is Open Source, it is developed solely by Google. This means that information on the internals of Android, its structure and how it is extended are hard to come by. There are few, reliable resources that cover how to build Android and even less that give information on how to extend specific parts such as the hardware abstraction layer or the System Server. Another pitfall for securing Android as a platform is its permission system which is tailored towards the app ecosystem. This permission system controls which app has access to what data and resources. For example, an application that wants to take pictures needs the CAMERA permission. However, in previous works it 1

8 2 CHAPTER 1. INTRODUCTION has often been criticized that this approach to protect data and resources is too coarse grained because it only controls whether an app may use a resource at all but not when and how the resource may be used. The goal of this work thus has to be to gather the necessary information on the internals of Android and to put this knowledge to use. This means first of all to identify the components of the Android stack that are relevant to extend Android with new hardware and second to understand how the components interact with each other and, third to find the correct way to integrate new components. In this work we will first provide background information on the details of the Android stack that are relevant during the rest of this thesis. In Chapter 3 we will describe the initial approach and eventual modifications to the Android stack which will allow generic access to GPIO hardware and its integration with the TaintDroid framework which we use as an example for dynamic taint analysis frameworks. This framework represents one approach to enhance and improve the coarse grained permission system. Additionally, we will implement a test application to test and evaluate the previously mentioned modifications. The evaluation will be described in detail in Chapter 4 after which we will discuss future and related work in the Chapters 5 and 6. Finally, we will conclude this work by assessing Android s capability to become the standard platform for IoT.

9 Chapter 2 Background In this section we will give some background information on the internals of Android and on the idea of Taint Analysis. 2.1 Android Android as an operating system is a software stack that is based on Linux. In the following sections we will describe the Android architecture based on the Android Open Source Project (AOSP). It provides the open sourced components of Android and some information on building and customizing Android. Figure 2.1 gives an overview of the components in the Android stack, which are part of the Android Open Source Project (AOSP). The core of the software stack as in all Linux-based systems is the Linux kernel. However, in contrast to most Linux distributions Android cannot run on a vanilla, i.e. unmodified kernel. So called androidized kernels contain a number of modifications in order to run efficiently on mobile devices with limited battery and memory. Furthermore they are crucial for Android s user-space components to run Android specific kernel changes The most important Android specific kernel components for this work are logger and Binder. Logger is the implementation for Android specific log messages, which is completely separate from normal kernel messages. Two logging mechanisms usually exist in Linux systems. The first is the kernel log which contains messages from within the kernel and the second is the system log which is used to log messages from daemons and processes in the system[21][7]. The logger driver replaces the system log. This driver writes messages coming from within the Android stack to circular buffers in the RAM where each buffer is accessible as an entry in /dev/log/. Various libraries and applications (e.g. liblog, logcat) make use of this driver and thus make up the logging framework. The most interesting one of the Android specific components for our work is the so called Binder. Binder is an inter-process communication (IPC) mechanism which allows implementing services as remotely invocable objects. In order to 3

10 4 CHAPTER 2. BACKGROUND Figure 2.1: The Android stack make use of new services all that is needed is the service s interface definition and a reference to the service[21]. Binder is the mechanism that is used in Android to enable apps to communicate with each other, with system services and through system services with lower level functionality. So when we talk about Binder we are in fact talking about a framework which is meant to enhance component and object communication in the operating systems and also about a driver which is part of the Linux kernel. The driver part of the Binder mechanism is accessible as a character driver through /dev/binder [12][6][7]. Along with other android-ism Binder was accepted into the Kernel staging area in Linux 3.3[14] and accepted into the main Kernel in Linux 3.19[13]. As the rest of the specific changes[21] to the kernel are of not essential for this work, we will not cover them in detail Hardware Abstraction Layer The hardware abstraction layer (HAL) is Androids method of providing hardware support. This is fundamentally different from the way hardware support is done in standard Linux distributions, where hardware drivers are either loaded dynamically at runtime or are part of the Linux Kernel themselves. The hardware is then usually made accessible by the drivers via /dev entries[7]. In Android however hardware support for services and libraries is provided by additional shared libraries. Those libraries are not part of the Linux kernel but are provided by the device manufacturers. These libraries are called HAL modules. In consequence this means that hardware is not automatically accessible via /dev entries for user space applications but has to be made accessible through the HAL. Figure illustrates the architecture of the HAL. Accessing hardware through the HAL means making use of libhardware s ability to load HAL modules. The libhardware library loads modules with dlopen() and thus provides a system service with the functionality of some hardware. Even though there are other methods of using shared libraries to access the hardware, we will focus on this approach when implementing our own HAL module (see Chapter 3). Informally the HAL can be described as a system which loads hardware-driver

11 CHAPTER 2. BACKGROUND 5 Figure 2.2: The hardware abstraction layer libraries, which ultimately use functionalities of the Linux kernel to access the hardware. The main advantage for hardware manufacturers is the ability to use proprietary libraries for providing the main functionality of a hardware device while still using the GPL licensed Linux kernel[21] Libraries On top of the Linux kernel Android provides more than 100 libraries which are partly coming from external projects such as OpenSSL and D-Bus or are created from within the Android Open Source Project such as the C library or Binder library. 1 The dynamically loaded libraries are located in /system/lib Runtime Components The runtime for Android applications consists of a number of different components which we will discuss in this subsection. The first one to mention is the libandroid runtime.so library. Its job is to start and manage the Dalvik Virtual Machine. Most notably it provides the app process command which allows to start a Dalvik VM. This library is also sometimes called the Android Runtime which is not to be confused with ART, which is also called Android RunTime and which replaced the Dalvik VM in Android 5.0. The Dalvik VM is a virtual machine which executes byte-code. This byte-code is generated by post-processing Java byte-code so that it matches the Dalvik VM. Instead of using the standard Java Virtual Machine (JVM), the Dalvik VM was developed to specifically target embedded devices. Apart from implementation details, the main differences between the Java Virtual Machine (JVM) and the Dalvik VM are that the Dalvik VM uses files in the Dalvik EXecutable format (dex) instead of class files. As mentioned before, the dex files are generated by post-processing class files. This means that at first the Java Compiler is used driver 1 libbinder.so, the Binder library is used by apps and services to access the Binder kernel

12 6 CHAPTER 2. BACKGROUND to generate class files from the Java code. Afterwards those class files are fed to a tool called dx which transforms them into dex files[3][21, p. 60]. Another notable difference is that the Dalvik VM only exists for Android whereas the JVM exists for multiple platforms. Finally, we want to mention that the Dalvik VM and the JVM have different types of executables. They are called Android Package Kit (APK) files for the Dalvik VM and Java ARchive (JAR) files for the JVM. Other important parts of Android which need to be known if we want to understand how applications are started are the Service Manager, the System Server and the Zygote process. The Service Manager process works as Binder s context manager, which allows services to be found through Binder via a naming system. This means that after a system service has been registered at the context manager other Binder clients (e.g. an app) can request a handle for the System Service from the Service Manager. The System Server is a process which is responsible for starting the system services and registering them at the Service Manager. This process is started at system startup with the app process command by Zygote. Zygote is another process which is started at system startup. Briefly, the job of Zygote can be described pre-loading all Java classes into RAM and then, when called, launching apps by forking itself. 2 The only process that is explicitly started by Zygote is the System Server. As a side-note it should be mentioned that the Dalvik VM was only used by default until Android 5.0 and was replaced by the Android RunTime (ART). ART is not a virtual machine but a ahead-of-time compiler which translates the byte-code of an application into system-dependent native code at install time System Services System services are the big enablers of the Android operating system. Any app that is doing anything remotely useful and interesting is interacting with some of the 50 to 70 system services even if app developers or app users might be oblivious to this. Most services are written in Java while some are done in C/C++. Even though system services are hardly mentioned in the Android Developer Guidelines, they are in combination with Binder what makes Android so consistent and easy to use for app developers Java API Framework On top of the Runtime sits the Java Application Programming Interface (API) Framework for Android. This framework consists of different APIs which provide functionality for Android apps to utilize all the underlying components of Android. These APIs are for example used when apps want to call on a system service to retrieve some information, e.g. contact data, or execute some action such as activating Bluetooth. The most visible feature of those APIs is the access to the view system which allows to build complex user interfaces. 2 For more details on Zygote see [21] 3 As we mentioned before, Binder allows apps to retrieve a handle to a system service from the Service Manager.

13 CHAPTER 2. BACKGROUND System Startup In order to put the components we mentioned so far in context we will have a brief look at the system startup of Android (see Figure 2.1.7). Figure 2.3: Control flow for system startup After the Linux Kernel has started Android s init process starts(1) and performs the steps configured in its init.rc file. During this process global properties are set and native daemons are started(2). This is when the Zygote process is started with the app process command (3). Subsequently, the System Server is started(4). The System Server then starts the system services and registers them with the Service Manager(5). The system services are responsible for loading HAL modules if they need them and once they have been registered at the Service Manager they can be used by other services or apps. 2.2 Dynamic Taint Analysis Dynamic Taint Analysis is an approach for real-time monitoring information flow in software systems. This form of software analysis is especially useful if the source code of an application is not available as static code analysis can be much harder in this case. In order to monitor the information flow in a system the data has to be marked at the time it enters the system. The process of marking data is called tainting and the place in the system where tainted data originates is called taint source. Accordingly, the place where tainted data may leave the system, e.g. a network interface, is called taint sink. This being said, we can observe two major tasks each framework for dynamic taint analysis has to perform. First, taking care of the storage of taint tags and second, managing and monitoring the propagation of taint tags within the system. Both tasks can be divided into sub tasks and the way they are achieved depends greatly on the target system and the way the framework is implemented. In our case the target system is Android 4.3 and the framework used is TaintDroid[8]. TaintDroid

14 8 CHAPTER 2. BACKGROUND is implemented by modifying the Dalvik VM itself and its integration into the Android stack. Figure 2.4: TaintDroid architecture as described in [8] The size of tainted data may vary from framework to framework, such as single bits, bytes or variables. The tags themselves may then be stored in taint maps or shadow memory. TaintDroid stores taint tags as 32-bit bit-vectors adjacent to 32-bit variables. This allows 32 distinct taint markings, each corresponding with a taint source[8]. This is achieved by modifying the Dalvik VM in such a way that each variable takes up twice the space it usually would and thus providing the necessary memory for the shadow variables containing the taint tag. The more complex task for the TaintDroid framework is taking care of the propagation of taint tags within Android. The complexity stems from the fact that taint tags have to be tracked within the modified Dalvik VM, when native code is executed, between processes as well as when data is written to files. When data items are created at a taint source, i.e. creation of variables, a corresponding taint tag is created which contains the taint marking for the source of the data item. During the runtime of the application taint tags may be combined through simple bit operation and eventually evaluated at the taint sinks. Native code is not monitored by TaintDroid itself, instead two post conditions are defined for accurate taint tracking. The first is, that all variables accessed by native methods are assigned taint tags and second that the return values of native methods are assigned taint tags as well. This is called method-level tainting. Those post conditions also imply that the operating system itself is trusted. This of course may lead to errors when tainted data is used in native code as taint tags may be modified or lost in native code unbeknownst to the taint analysis framework. As each VM runs in its own process and uses IPC it is necessary to make it easy to propagate taint tags between processes alongside the exchanged data. This is done via so called message-level tainting where the taint tag of an IPC message is represented by the upper bound of all taint markings in the message. Message-level tainting may lead to false positives as all variables in the message share the same taint markings after unpacking but may not have had all the taint markings at send time. According to [8] message-level tainting is necessary and chosen over variable-level tainting as a receiver of the message could remove taint markings from single variables by unpacking them differently and thus removing the markings.

15 CHAPTER 2. BACKGROUND 9 The last part where taint tags need to be propagated is when data is written to a file. TaintDroid stores a single taint tag per file, which is subsequently updated each time tainted data is written to a file and attached to data that is read from the file. For this, an extended attribute support was implemented for Androids host file system so that taint tags can be stored in said extended attributes. Similar to taint tags in IPC messages, this so called file-level taint tracking, can lead to false positives as all data items in the file share the same taint tags and thus may have more taint markings as the original data items had before writing to the file. We are thus basing the rest of this work on Android 4.3 and after making our modifications incorporate TaintDroid into the Android build and set new taint sources in our newly written system service (i.e. GenGpioService).

16 Chapter 3 Implementation In this Chapter we will first present the conceptual approach we have taken for the implementation of this work. Subsequently, we will describe the implementation details for the system service and the components that need to be extended to add a new system service to the Android stack. Afterwards we will go into the implementation details of a HAL module we provide and how it is used by the other components 3.1 Conceptual Approach Our implementation goal is to provide a security enabled middleware for Android on ODroid. This means we want to provide a middleware for Android which enables users to generically access data that is provided by sensors for which there may not be a driver included into the Android build. It has to be security enhanced which means that additionally to the, often as coarse grained criticized[8][16], permission system of Android, the middleware should allow sensor data to be tracked on its way through the system. Finally, the modified Android should be able to run on ODroids. In order to provide a middleware for Android we plan to extend the hardware abstraction layer by providing a module that accesses sensors and actuators connected via GPIO. The module will then be utilized by a system service that will provide apps with generic data. The idea is that the HAL module and the system service do not provide any interpretation of the data but leave this to the app which is indirectly accessing the sensors or actuators. While forcing the app developer to have knowledge about the used hardware, this allows apps to access them through a generic interface and more importantly doing so without root privileges. Ultimately this means that app developers can make use of sensors and actuators which are not supported by standard Android. We will rely on dynamic taint analysis as an enhancement to Android s permission system. As described in Chapter 2, the taint analysis framework we will use is TaintDroid. It is open source and can be obtained online[19]. There exist versions of TaintDroid for Android 2.1, Android 2.3, Android 4.1 and Android 4.3 which can be integrated into an Android build by modifying various components such as the Dalvik VM. In order to test the generic sensor access and the taint analysis framework 10

17 CHAPTER 3. IMPLEMENTATION 11 a test app will be needed which utilizes both components and simulates an untrusted third-party app. The goal is to access sensor data and have the data leave the system at a taint sink. A new taint tag for the sensor data will be created so it can be recognized that the data is not allowed to reach a taint sink. The used taint analysis framework is then expected to recognize this misuse and alert the user of the system. As actuators do not provide data but instead consume it, they could theoretically function as taint sinks instead of taint sources. This of course implies that data sent to an actuator actually originates from a taint source and not from user input. The hardware we planned to use, is an Odroid XU-4 as a device running with an Android 4.3 distribution. The Odroid XU-4 was chosen as it provides both the possibility to run Android and has enough computing power to work as a server for a smart home as was shown in the Practical Course for Engineering of Networked Systems during the winter semester 2015/2016. Android 4.3 as a specific version is necessary as it is the latest version that is supported by TaintDroid. TaintDroid in turn was chosen as it is the most complete taint analysis framework that is freely available and well documented[19]. The implementation phase is divided into four parts. The first part is the implementation of the system service which is followed by the implementation of a HAL module. Integrating the system service into the TaintDroid framework will be the third part. As a fourth step we implement a test application that is used to gather data and execute tests which provide the basis for the evaluation in Chapter 4. The additional goal would have been to implement build files for Android to create an image targeting the ODroid XU-4. Due to the grave mis-balance between the time we would have had to invest and the overall relevance for this work we did not pursue this goal further. 3.2 System Service The folder structure for the System Service can be found under /framework/base and is shown in more detail in Appendix A: The files under /frameworks/base/core are defining the interface and relevant constants of our new system service while the logic of the service itself is found under /frameworks/base/service IGenGpioService The first file that we created was IGenGpioService.aidl. The AIDL, which stands for Android Interface Definition Language, is Androids way to define interfaces for clients and services in IPC. In this case the system service we created is the server and Binder which will get a handle of the system service is the client[1]. In our case the defined interface contains only two methods, one for reading a certain amount of bytes from a sensor and one method to write bytes in a string to a sensor. 2 package android. os ; 3 i n t e r f a c e IGenGpioService { 4 / 5 {@hide}

18 12 CHAPTER 3. IMPLEMENTATION 6 / 7 S t r i n g read ( i n t maxlength, i n t g p i o p i n ) ; 8 i n t w r i t e ( S t r i n g mstring, i n t g p i o p i n ) ; 9 } Listing 3.1: IGenGpioService.aidl GenGpioManager System services in Android are generally not exposed to the SDK. Instead, another layer of abstraction is added which allows performing other tasks, such as logging or exception handling, alongside the call to the system service itself. This layer consists of the Manager classes, such as the WifiManager for the WifiService. According to this design principle we created the GenGpioManager class. This class wraps the call to the service and performs simple exception handling. The GenGpioManager has, due to its simplicity, the same interface as the service itself (see IGenGpioService.aidl). To make the manager usable by apps the Context.java and ContextImpl.java classes have to be patched with the following code / 2200 Use with #g e t S y s t e m S e r v i c e } to r e t r i e v e a 2201 android. os. GenGpioManager} f o r u s i n g GenGpioService #g e t S y s t e m S e r v i c e 2204 / 2205 p u b l i c s t a t i c f i n a l S t r i n g GENGPIO SERVICE = gengpio ; Listing 3.2: Patch for Context.java 551 r e g i s t e r S e r v i c e (GENGPIO SERVICE, new S e r v i c e F e t c h e r ( ) { 552 p u b l i c Object c r e a t e S e r v i c e ( ContextImpl ctx ) { 553 IBinder b = ServiceManager. g e t S e r v i c e (GENGPIO SERVICE) ; 554 IGenGpioService s e r v i c e = 555 IGenGpioService 556. Stub 557. a s I n t e r f a c e ( b ) ; 559 r e t u r n new GenGpioManager ( s e r v i c e ) ; 560 }}) ; Listing 3.3: Patch for ContextImpl.java The first code snippet defines the constant that can be used in apps when requesting the service and the second snippet adds the GenGpioManager to the Map containing all Manager classes that can be requested by an app GenGpioService The system service consists of two files, the first is the GenGpioService class supplemented by the native methods from the com android server GenGpioService.cpp file (see Appendix C). 1 The complete code can be found under frameworks_base/tree/taintdroid-4.3_r1/core/java/android

19 CHAPTER 3. IMPLEMENTATION 13 The GenGpioService implements the previously mentioned IGenGpioService interface, thus providing the read and write functionality. When the service is first initialized, it calls the init native () method to load the HAL module. The init method returns a pointer to the module which is then used to reference the module when making calls to its read and write functions. Additionally, the onload.cpp has to be extended with two lines in order to register the native methods so the Java part of the service can use them. 2 Finally the SystemServer.java had to be patched with the following code. 701 t r y { 702 Slog. i (TAG, GenGpio S e r v i c e ) ; 703 ServiceManager. a d d S e r v i c e ( 704 Context. GENGPIO SERVICE, 705 new GenGpioService ( c o n t e x t ) ) ; 707 } catch ( Throwable e ) { 708 Slog. e (TAG, F a i l u r e s t a r t i n g the GenGpio S e r v i c e, e ) ; 709 } Listing 3.4: Patch for SystemServer.java This code snippet is what allows the Service to be loaded via the ServiceManager as it is used in the ContextImpl class that was shown above. 3.3 HAL Module Creating a new HAL module is the only device specific action that was necessary for this work. Initially we planned on providing a module that targets the ODroid XU-4. A precondition for this is of course that there are working build configurations for the correct version of the AOSP targeting this specific device. As those build files did not exist for the Android version 4.3 we set a two-week time slot during which we tried to port Android 4.3 to the ODroid XU-4. After having great difficulties with porting the device and not succeeding in the time slot that was set, we ultimately decided not to pursue this task further. This was only a minor aspect of this work and we found that the emulator could be used as a suitable alternative to implement and test a HAL module. Defining a new hardware type is done by creating a new header file, in our case the gen_gpio.h under /hardware/libhardware/include/hardware. A new HAL module is subsequently created by providing a shared library based on this header file. In our case the implementation can be found in the gen_gpio_qemu.c file. 1 #i f n d e f ANDROID GEN GPIO INTERFACE H 2 #d e f i n e ANDROID GEN GPIO INTERFACE H 4 #i n c l u d e <s t d i n t. h> 5 #i n c l u d e <s y s / c d e f s. h> 6 #i n c l u d e <s y s / types. h> 8 #i n c l u d e <hardware / hardware. h> 10 BEGIN DECLS 12 # d e f i n e GEN GPIO HARDWARE MODULE ID g e n g p i o 2 The modifications can be seen in Appendix D in lines 29 and 57

20 14 CHAPTER 3. IMPLEMENTATION 14 s t r u c t g e n g p i o d e v i c e t { 16 s t r u c t h w d e v i c e t common ; 17 i n t ( read ) ( char b u f f e r, i n t length, i n t g p i o p i n ) ; 18 i n t ( w r i t e ) ( char b u f f e r, i n t length, i n t g p i o p i n ) ; 19 } ; 21 END DECLS 22 #e n d i f // ANDROID GPIO INTERFACE H Listing 3.5: gen gpio.h In the header file we can find the GEN GPIO HARDWARE MODULE ID. It is the basis for the file name of the shared library that can be loaded as this HAL module. When the HAL tries to load a module it will look in /system/lib/hw for a file with the name pattern <HARDWARE MODULE ID>.<DEVICE CODE NAME>.so. The shared library for this module targeting the emulator is thus called gen_ gpio.goldfish.so 3. In order to provide a HAL module for a specific device the files needed to create the shared library have to be placed in the lib* directory of a device. This is the same directory that contains the build instructions for a Android build targeting a specific device. In case of the ODroid XU-4 this would have been the directory under device/hardkernel/odroidxu-4/. The emulator is a special case though, as its build files are not located in the device folder but in sdk/emulator. This means that our implementation of the HAL module can be found in sdk/emulator/gen_gpio/gen_gpio_qemu.c. The implementation of our HAL module simply mocks the access to a sensor as there are no real sensors available for the emulator. It can nevertheless be loaded by the libhardware library and subsequently used by the GenGpioService. When the service tries to read from the mocked sensor, it always returns a 1 and when the system service writes to the sensor, the data written is simply discarded. If a more sophisticated logic was necessary to test some special behavior, the read and write methods of the module could simply be modified and used for testing. The most important parts of the implementation are the following code snippets. They allow the shared library to be recognized by the HAL as a module that can be loaded. 76 s t a t i c s t r u c t hw module methods t gen gpio module methods = { 77. open = o p e n g e n g p i o 78 } ; 80 s t r u c t hw module t HAL MODULE INFO SYM = { 81. tag = HARDWARE MODULE TAG, 82. v e r s i o n m a j o r = 1, 83. v e r s i o n m i n o r = 0, 84. i d = GEN GPIO HARDWARE MODULE ID, 85. name = Generic GPIO HW Module, 86. author = Christoph F r a e d r i c h, 87. methods = &gen gpio module methods, 88 } ; Listing 3.6: HAL structs in gen gpio qemu.c 3 Goldfish is the device code name for the emulator

21 CHAPTER 3. IMPLEMENTATION 15 The HAL MODULE INFO SYM struct is what is returned to a system service, when it loads a HAL module by calling the hw get module function. It in turn contains a pointer to the open function, that is called in the init native () method, that is executed when the system service is started (see Appendix C). Also note that the open function points to the open gen gpio function, which fills the gen gpio device t struct we have seen earlier in the gen gpio.h file. This struct is what eventually gets used in the service to access all the methods provided by the HAL module. 61 s t a t i c i n t o p e n g e n g p i o ( c o n s t s t r u c t hw module t module, char c o n s t name, s t r u c t h w d e v i c e t d e v i c e ) { 62 s t r u c t g e n g p i o d e v i c e t dev = malloc ( s i z e o f ( s t r u c t g e n g p i o d e v i c e t ) ) ; // Reserve memory f o r d e v i c e s t r u c t 63 memset ( dev, 0, s i z e o f ( dev ) ) ; // Clear memory area 65 dev >common. tag = HARDWARE DEVICE TAG; 66 dev >common. v e r s i o n = 0 ; 67 dev >common. module = ( s t r u c t hw module t ) module ; 68 dev >read = g e n g p i o r e a d ; 69 dev >w r i t e = g e n g p i o w r i t e ; 71 d e v i c e = ( s t r u c t h w d e v i c e t ) dev ; 73 r e t u r n 0 ; 74 } ; Listing 3.7: HAL functions in gen gpio qemu.c 3.4 TaintDroid TaintDroid has made major modifications to the AOSP and its source code is available on GitHub. According to the build instructions we obtained the Android source code and patched it with the modifications made by TaintDroid. This can be done by creating a local manifest.xml and re-syncing repo. 4 This will replace the stock AOSP components with their modified counterparts from TaintDroid. We in turn made modifications to files already in the AOSP (see 3.2) and thus could not simply replace the standard files with ours by syncing from our repository as we would have overwritten TaintDroid s modifications or vice versa. To solve this problem we simply forked the projects we needed to modify and patched them with our changes. 5 First of all we added the new files and patched the files already shown in Appendix A. TaintDroid allows 32 distinct taint markings and already predefines and uses 16 of those. The taint markings are defined in dalvik/vm/ interp/taint.h for the DalvikVM itself and in libcore/dalvik/src/main/ java/dalvik/system/taint.java for Java libraries. The Taint.java class also provides the functionality we later used to taint data. In order to create a tag that identifies our new service as a taint source we only had to add a new 32-bit vector as a constant to both files. Ultimately we had to patch the read method in the GenGpioService by adding the taint before returning the data we read from the HAL module. 4 TaintDroid provides detailed build instructions on its website[19] 5 The forked repositories can be viewed on

22 16 CHAPTER 3. IMPLEMENTATION 40 p u b l i c S t r i n g read ( i n t maxlength, i n t g p i o p i n ) { 41 i n t l e n g t h = 0 ; 42 byte [ ] b u f f e r = new byte [ maxlength ] ; 44 l e n g t h = r e a d n a t i v e ( mnativepointer, b u f f e r, g p i o p i n ) ; 46 S t r i n g v a l u e s ; 47 t r y { 48 v a l u e s = new S t r i n g ( b u f f e r, ISO ) ; 49 Log. d (TAG, Bytes read : + v a l u e s ) ; 50 } catch ( Exception e ) { 51 // do nothing h e l l o 52 v a l u e s = ; 53 } 55 // begin TAINT TRACKING 56 i n t tag = Taint. TAINT GENGPIO; 57 Taint. addtaintstring ( values, tag ) ; // t a i n t value i s added i n p l a c e 58 Log. d (TAG, Add Taint i n GenGpioService w h i l e r e a d i n g ) ; 59 // end TAINT TRACKING 61 r e t u r n v a l u e s ; 62 } Listing 3.8: Read method with taint tracking If our HAL module would act as a taint sink we would patch the write functionality in the GenGpioService to check if a variable we write to the module contains a taint tag and if so, write a log message to the Android log. 3.5 Difficulties during the implementation The biggest challenges during the implementation were of a non-technical nature. As the name of the Android Open Source Project implies the source code of Android is freely available but additional information is hard to find and troubleshooting information even more so. Overall the biggest stepping stone for development of Android system components, especially for embedded devices, is how difficult it is to find reliable information on the internals of Android. Apart from [21] we did not find a comprehensive description of the AOSP which covered every aspect of the Android stack that is relevant for our work. The second biggest challenge was the vast number of different and often incompatible versions of each component that we are using. Up to date there are eight major versions of Android with various sub-versions. TaintDroid covers four minor versions and Hardkernel provides build files for six other minor versions of Android. Unfortunately the versions for TaintDroid and the ODroid do not match. When trying to create build files which matched the Android version TaintDroid uses, we relied on the limited information we found online. However we did not manage to finish a build without errors. Another example is the TaintDroidNotify app. Even though there is a version targeting Android 4.3 you have to use the app for version 4.1 as version 4.3 contains a bug where the background service which evaluates the log does not work properly[2].

23 CHAPTER 3. IMPLEMENTATION 17 Probably the most time consuming pitfall that in the end had a very simple solution was that the example code for a HAL module provided by [21] contains a bug which leads to the emulator not starting. 3.6 Summary The implemented system service makes use of the hardware abstraction layer and thus is independent of specific driver implementations. Different HAL modules can be provided where the only similarity they have to share has to be the definition of the module interface that was provided during this work. The system service can, when a module is provided, be used to read generic byte arrays from sensors connected via GPIO, where the data is tainted by the TaintDroid framework. The system service also enables users to write generic byte arrays to sensors and actuators. It also makes use of the TaintDroid framework and thus allows to track tainted data read from sensors throughout the system. Lastly, if the TaintDroidNotify app is installed, it allows receiving notifications when data, read by the GenGpioService, reaches a taint sink. At the time of writing it is not yet possible to run Android with the securityenabled middleware on ODroid as a working Android build for Android 4.3 does not exist for this device and there is no tested HAL module for the GenGpioService targeting an ODroid XU-4. Also, the HAL modules used by the GenGpioService are currently not functioning as taint sinks as this did not seem reasonable for the mock implementation of a GPIO-connected sensor. In case this would be needed for a HAL module the write method in the GenGpioService could easily be extended to evaluate taint tags before writing to a sensor Integration into the Android stack The best way to show how the components we added during this work integrate into Android is to revisit system startup we briefly described in Chapter 2. We will once again start our evaluation after the Linux Kernel is up and running and Androids init process is started. Figure illustrates the startup process. Figure 3.1: Control flow for startup with new components The steps (1-5) remain the same as before. Step 5 now includes our newly

24 18 CHAPTER 3. IMPLEMENTATION implemented GenGpioService, which gets started by the System Server and registered at the Service Manager(see 3.4). The GenGpioService then loads the HAL module by calling its init native () method. In this method we call the hw get module() with the ID for the HAL module we want to load(6). hw get module() then opens the shared library, which represents the HAL module for the given ID, with dlopen() and returns a handle to the shared library and can subsequently be used in the system service(7). Note that this sequence of initialization also includes the changes made by TaintDroid. The modifications made to the Dalvik VM are in effect when the Android Runtime starts the first Dalvik VM, the modifications made to the system services are working when the System Server starts the system services and a service added by the TaintDroidNotify app can be started after the app is started by the ActivityManagerService. 6 6 The ActivityManagerService is one of the many services that gets started by the System Server

25 Chapter 4 Evaluation In this Chapter we want to show how the newly added system service and HAL module work within the Android stack alongside TaintDroid. For this we will describe how the components interact with each other when data is read from a sensor and written to a taint sink. The description of the test applications we used to ensure that all components are working as planned will complete this Chapter. 4.1 Component interaction behavior Figure 4.1 shows the various calls that get executed when the TaintViolationTester app requests data (i.e reading) from a sensor. In the rest of this section we will assume that the GenGpioService was registered at system startup and an appropriate HAL module is present and was successfully loaded. The first step is requesting the handle to the GenGpioService from the Service Manager through Binder(1). After the app has received a handle to the system service, it can call on its read function(2) which gets forwarded to the HAL module(3). The HAL module eventually returns the requested number of bytes it read from the sensor(4) which the GenGpioService returns to the app through Binder(5). In the next step the app will attempt to send the tainted data to a web service through network socket(6). Since the network socket is also a taint sink it will not only send the data to the web service(7a) but also evaluate the taint and write a log to the log driver(7b). If the TaintDroidNotify app was used to activate its service for notifications regarding tainted data leaving the system, said service will evaluate the logs from the log driver through the logcat tool(8). Whenever a log, such as the one issued in step(7b) is read, the service requests a handle for the NotificationService through Binder (9a) and then issues a notification for the user with the information from the log message (9b). Note that for more clarity we omitted the manager classes for the services in this diagram. This is because they would only be displayed as wrappers around the services which only forward the calls and provide little information that helps to understand the flow of information and the sequence of calls. In case of writing to a device the steps are similar to the steps (1-5) only different in the fact that the write method is called instead of the read method and that we do not return bytes read, but the number of bytes written. 19

26 20 CHAPTER 4. EVALUATION Figure 4.1: Execution behavior 4.2 Android Test Applications TaintDroid itself provides an Android app called TaintDroidNotify. This app allows a user to start a TaintDroidNotifyService which operates on the application level and is not part of the operating system. It scans the Android log for messages indicating that tainted data reached a taint sink. In case it detects such a log entry it displays a notification to the user describing the data and the taint type. This app can be added to the build by placing the source files of the app under packages/apps. Additionally, we developed a second test app that allows a user to send tainted and untainted data to a web service. The application consists only of one Activity displaying two buttons. If the Send Untainted Button is pressed a untainted string is sent to the web service as a HTTP POST request. If the Send Tainted -Button is pressed the app requests a GenGpioManager object and utilizes its methods to read data from the sensor via the GenGpioService and sends it to the web service as a HTTP POST request (see 4.1). 40 p u b l i c void onclick ( View view ) { 41 GenGpioManager manager = ( GenGpioManager ) g e t S y s t e m S e r v i c e ( Context. GENGPIO SERVICE) ; 42 S t r i n g gpiodata = manager. read ( 3 2, 0) ; 43 new SendDataTask ( ). e x e c u t e ( http : / / p o s t t e s t s e r v e r. com, gpiodata ) ; 45 Log. v (TAG, Send t a i n t e d ) ; 46 } Listing 4.1: Sending tainted data

27 Chapter 5 Future Work Future work for the security-enabled middleware for Android on ODroid covers two aspects. The first is the future work regarding the middleware we presented in this work and second being security-enabled middleware for Android in general and possibly other taint analysis frameworks. Regarding the security enabled middleware presented here the most prominent feature missing at the time of writing certainly is the missing possibility to run Android with the middleware on the ODroid XU-4. This is because there are no appropriate build files for Android 4.3 targeting this device. In order to create working build files in-depth knowledge of the Android build system is necessary along with knowledge of the hardware components of the ODroid XU-4. When those build files are created the middleware can easily be integrated into the Android build and a new HAL module for the ODroid can be created. As soon as those steps are completed, the security enabled-middleware will be fully usable by Android systems running on ODroid XU-4 devices. Additionally to the ODroid XU-4, other devices that run Android could be used as well, as long as there are build files for the device and a HAL module gets implemented for the device. In this work we have focused solely on creating components for the Android stack that target devices connected via GPIO. Regardless of the way sensors and actuators are connected to a system, their usage might leak privacy sensitive information, therefore we suggest incorporating other connection types, such as USB or other peripheral I/O, into the security enabled middleware. Additionally, the connection types that already exist in standard Android such as WiFi need to be tested with sensors using them, to determine whether they are covered by the used taint analysis framework or not. Android 4.3 is already four years old. In the meantime several newer Android versions as well as Android Things have been released. Android Things as an operating system specifically targets embedded and IoT devices. A very interesting research topic is to adapt this work for a current version of Android or Android Things. In the case of Android Things a system service specifically targeting generic GPIO connections might not be necessary as Android Things already supports GPIO connections. A pre-condition for adapting this work for newer versions of Android is that there is a taint analysis framework which targets ART which replaced Dalvik in version 5.0. A possible framework for this is TaintArt which was developed for Android 6.0 Marshmallow. Even though 21

28 22 CHAPTER 5. FUTURE WORK the authors stated that the framework will be open sourced, the source code was at the time of writing not available online[18].

29 Chapter 6 Related Work TaintDroid, which we described extensively in Chapter 2, is the basis for the taint analysis framework Kynoid[16]. Kynoid extends the functionality provided by TaintDroid by allowing user-defined policies for individual data items which are enforced at taint sinks. To achieve this it uses the shadow memory available due to the modifications to the Dalvik VM for IDs, instead of identifiers for taint sources. These IDs are attached to variables and get associated with the defined policies. TaintArt and ARTist are frameworks with the same goal as Taintdroid, i.e. enabling dynamic taint analysis on Android. Both frameworks are developed for newer Android versions which use the Android RunTime (ART) instead of the Dalvik VM[18][5]. The differences in design of both frameworks in comparison to TaintDroid are as fundamental as the differences between using the Dalvik VM and ART. ART does not interpret bytecode at runtime but uses ahead-of-time compilation of entire applications at install time. Both TaintArt and ARTist modify the so called dex2oat compiler to implement taint tracking. TaintArt stores taint tags primarily in processor registers whereas ARTist uses the local storage of the thread that contains tainted data. Unfortunately we did not get access to the source code of neither TaintArt nor ARTist which prevented us from using it in this work alongside a newer version of Android instead of TaintDroid and Android 4.3. FlowDroid is an approach to analyze Android apps statically without actually executing them[4]. It generates and analyses call graphs of an app by creating a dummy main method which emulates life cycles of the app components. The advantage over TaintDroid is that apps cannot cover their tracks in case they are designed to recognize that a taint analysis framework is installed. This stems from the fact that the apps get analyzed before they are installed on the system. This of course brings the drawback that apps, that are installed without being analyzed first can execute malicious actions without ever being detected. Generally comparing the advantages and disadvantages of FlowDroid and TaintDroid can be seen as a comparison between static and dynamic taint analysis for two specific tools. 23