Use of Sensors and Hardware Devices by Multiple Users

Hypothesis3from Section3.3.3was tested by a colleague, and therefore only summarized here as a way to provide additional evidence of how the methodology described earlier was put to use. Further details pertaining to the sensor and hardware testing are found in [34].

In this section, we aim to answer Hypothesis3from Section3.3.3. That is, non-logged in

secondary users can exploit improper access control enforcement on shared hardware resources to spy on current users. In fact, if Android does not enforce proper access control on shared hardware resources based on user status, a non-current user can still use a hardware interface to infer various information about the logged in users and spy on them. For example, if a non-current user can query the light and accelerometer sensors over a time interval, he can infer potential activities about current user such as whether he is sitting indoors, or jogging outdoors. Moreover, if he can query the GPS service, he can even infer where he is sitting or jogging. Even more

concerning, if he can launch the sound and camera recorders, he can know easily more details such as with whom he is and what type of conversation he is having.

Under single-user assumptions, all hardware interfaces belong to the same user without any concerns of misuse. Ideally, with multi-user features, a hardware resource should only be bound to a single user at a time, corresponding to the currently logged-in user. Since the hardware interfaces are shared among the users on an Android device, the transition from single to multiple user framework requires changing the access control model on all hardware resources to make

sure that use of a hardware resource is only granted to the logged in user.

To ensure that a hardware resource is only bound to the currently logged in user, Android should be able to identify if the user requesting a resource is logged in. Also, it should track if the user who initiated the request is continuously logged in during the service lifetime. More specifically, if user-switching occurs, Android should be able to revoke any resource access from non-logged in users. Thus, the hypothesis testing in this section focuses on whether or not Android access control enforcement for shared hardware resources factors in user status. Media resources and common sensors are each tested against the hypothesis: for each resource, an test app is designed that will attempt to access a resource even if the user running the app is not logged in. This approach exploits the fact that ActivityManager does not kill all non-current user processes. Thus, the attacking app can be launched when the malicious user is logged in, and continues to run after he logs out and the victim user logs in. A non-owner user is deliberately chosen to be the attacker, and the owner to be the victim since non-owner is less privileged compared to the owner and represents the worst case. Findings for each of the resource categories are summarized below.

3.4.4.1 Media resources

To check if relevant access control points take into account multiple users, an test app was designed to launch the camera (without a preview window) and start video recording while the victim is using the device. The app is launched from the attacker user account (userId 10) and then the device is switched to the victim account (userId 0). The test app was observed to continue recording video while the victim is using the device. Since the test app is running as the attacker, the recorded video is saved under the attacker’s data directory and can be retrieved by the

attacker later. The success of the attack reveals that the media resource access controls only come into play at request-time and do not consider the changing of user status.

3.4.4.2 Motion, environmental and position sensors

Most Android devices have numerous built-in sensors such as motion, environmental, and position. Motion sensors include accelerometers, gravity, rotational vector sensors, and

gyroscopes. Environmental sensors measure ambient air temperature, pressure, illumination and humidity, while position sensors measure the physical orientation of a device. Unlike the media devices discussed above, activity from these sensors follow an event-driven approach. In other words, an app first registers a listener to receive sensor events through the SensorManager, then SensorService will deliver the sensor data to the registered listeners.

To test whether Android’s sensor access controls consider user state, a test app was developed to continuously log sensor data. Similar to how the video recording app was used, the sensor app is launched from the attacker account and then the device is switched to the victim user. Even after user switching, the app continues to receive sensor events, silently while the victim is using the device. Sensor data logs are stored in the attacker’s data directory and may be retrieved later. This success indicates that no access controls exist for the sensor devices, either at listener registration time or during sensor data delivery. The conclusion is that the sensor subsystem fails to consider the new

3.4.4.3 Location sensor

Tests similar to those above were performed on the GPS location sensor and found that a

non-current user cannot succeed in getting GPS location updates of the logged in user. A review of LocationManagerService code revealed that it does indeed apply proper access controls that consider user status when location data is dispatched. Specifically,

handleLocationChangedLocked() will only dispatch location updates to registered listeners belonging to the current user. In this case, LocationManagerService properly tracks the current user and updates its instance variable, mCurrentUserId, each time the user is switched. A similar

Chapter 4

Access Control Characterization

You can’t secure what you don’t understand.

- Bruce Schneier, Schneier on Security, 1999 [42]

4.1

Introduction

The previous chapter highlights the need to consider Android’s unique factors when evaluating or improving the platform’s security. These factors include its open design, decentralized,

resource-centric access controls, and emphasis on usability. Besides these, the phenomenon of vendor and carrier customization is another reality that sets Android apart from other mobile operating systems—and introduces a whole new dimension of security concerns.

Nearly all of the Android devices in use throughout the world are those which have been

customized by manufacturers and service carriers. Unlike devices running the open-source AOSP baseline, these customized devices run versions of Android that are proprietary and closed source. Designed to create a competitive advantage through product differentiation, typical modifications include the addition of pre-loaded apps, custom launchers, mobile device management (MDM) features, carrier-specific enhancements or restrictions. Previous work has studied the security

implications of some of these modifications, including hanging attributes references [43],

problems with pre-loaded apps [44,41,45], security configuration changes [46], and access control inconsistencies [47]. Other work has focused on automated detection of bugs in the Linux kernel [48,49,50] and and inconsistencies in its configuration options [51,52]. These and other related works are discussed in more detail in Chapter6.