Blog

Android Security Implications on ChromeOS

Recently, at ZIONLABS, we performed a security assessment of the Android runtime running on the Chrome operating system (ChromeOS). This runtime allows Chromebook users to install and use Android applications. In this blog post we discuss our findings and recommendations regarding the security posture of an Android application running on a Chromebook. First, we start with a short overview of ChromeOS. Secondly, we compare a rooted Android device with a Chromebook that operates in 'Developer Mode'. Finally, we conclude with our findings and recommendations with regards to Android application security on ChromeOS.

Chromeos

ChromeOS is a lightweight operating system that is built around the Chrome browser. It is based on the opensource Chromium project, developed and maintained by Google. The core security concepts are leveraged from the Chrome browser which means that every Chrome application is sandboxed. This ensures that no malicious third-party application can attack or compromise a benign application running and storing sensitive information in a different container on the Chromebook. Furthermore, Chromebooks ensure cryptographic verification of the operating system. The bootloader is stored in read-only memory (ROM) and the hardware verifies the signature which is stored in a trusted chip. Other classic Unix security mechanisms are also implemented to ensure proper process isolation by implementing a privileged user role-based access control and file-system permissions access model. It is however possible to switch the Chromebook into developer mode, which allows a user to get root privileges on the Chromebook and effectively bypassing the aforementioned security measures. Sandboxing and contained execution cannot be guaranteed as the root user has access to the entire filesystem and memory space of other processes. ChromeOS also offers the App Runtime for Chrome (ARC), which allows the installation and execution of Android applicationsin a trimmed down Android runtime. This runtime runs as the android-root user on the Chromebook and is contained from other Chrome applications that are running on the device. Inside the runtime, the traditional Android security measures are enforced, ensuring that the same level of sandboxing and memory isolation is achieved as on a regular Android device.

Developer mode vs rooted device

Now we will compare the developer mode of a Chromebook with an Android device that is rooted. Important to note here, is that switching a Chromebook to developer mode is not difficult, even more, it is made easy and quick. This means that there are not a lot of obstacles to take for a developer or malicious actor to get a root user on a Chromebook. However, also note that the device will be wiped every time it is switched to and from developer mode. Now, compared with the rooting process on Android, this is very easy and fast. Furthermore, applications on a rooted Android device do not really run with root privileges as such. They leverage a superuser (su) daemon that will perform the root operations for the application. This has the added benefit that an additional access control model can be implemented, requiring the user to grant root privileges to an application that wants to perform root-privileged actions. This is being enforced by the su daemon. This is not the case on a Chromebook: root access, means root access. Another important difference is multi-user usage of a Chromebook device with regards to a (rooted) mobile device. It is not often the case that a mobile device is shared between users. It is however far more often the case that a Chromebook device is shared between users.

Findings

We specifically focused on local storage isolation and the Android keystore implementation on Chromebooks. The following list are some of our security findings:

  • The local storage of an Android application is correctly implemented and secured when the Chromebook is not switched to developer mode. We were not able to access the Android runtime container, let alone, the private Android application space inside the Android runtime.
  • The local storage of an Android application is not properly contained when running the application on a Chromebook in developer mode. We could access the private application data directory inside the Android runtime. Furthermore, we could interact with the memory space of the application, which leads to various security issues that cannot guarantee the security and privacy of the user. See the figure below where we could inspect the process memory of an Android application, using a shell on ChromeOS.

  • In Android, it is security best practices to leverage the Android KeyStore to store sensitive encryption keys. Even though the Chromebook is running Android 6.0, there is no possibility for a hardware-backed keystore and or user password or pincode. The keystore heavily relies on the presence of a user supplied pincode to encrypt the master key used for encrypting keys in the keystore. There are two concrete security issues here: 1) The KeyStore is not hardware backed, nor a user can set a passcode or pincode to protect the masterkey that should be stored in the hardware chip in the first place. 2) A rootuser on a Chromebook in developer mode can freely read and/or alter the master key being used by the Android KeyStore on the Chromebook. The figure below shows the masterkey file.

Conclusion

We do not think security sensitive Android applications should run on a Chromebook in general. The Android runtime is not sufficiently protected when the Chromebook is switched into developer mode. When you write an Android application, you as a developer trust the underlying operating system (this case Android) to work as expected, however the security model of the Android runtime is completely altered on a Chromebook. It is strange that the Android runtime does not run seperately from ChromeOS. A root user in ChromeOS should not have access to the private application space of Android applications that run on the Chromebook. The Android runtime should run in a completely separated module, this to ensure that the same security measures are enforced that we know from the Android operating system.

references

Add comment