What information can a malicious Android app observe about the behavior of other apps running on the same phone?

In more detail, suppose app M is malicious and is running in the background. Suppose app A is legitimate and is running on the same phone. What information about A can M observe? What can M infer, about the behavior of A or the user's interaction with A?

I know that there are some files in /proc that are world-readable, so this would let M observe some (possibly innocuous) information about A by reading /proc/N/foo where N is the pid of some process in app A and foo is some world-readable file. What does this let M see? What can M infer, based upon this information?

Are there any other ways that app M can learn something about the behavior of app A? For instance, can app M learn what IP addresses app A is communicating with? Can app M learn whether app A is currently using some exclusive-access resource/sensor (e.g., the microphone, the camera, etc.)? Can app M infer anything about text being typed into app A through the on-screen soft keyboard?


On multi-core platforms at least (and most new smartphones are multi-core), all the side-channel attacks on branch prediction and cache should work, as long as the attacker can access a clock with enough precision. The ARM architecture has a "cycle counter" that application code can use, but it has to be first enable from privileged code (kernel); see this answer. Native code is possible for apps starting with Android 2.3 (with the NDK).

I don't know if the cycle counter is enabled by default with Android; it is disabled in a freshly booted CPU, but Android uses a Linux kernel and the cycle counter is very convenient for a number of tasks, including implementing the gettimeofday() system call, so it is possible that the Linux kernel enables it. This should be tested.

IF the cycle counter is enabled, then chances are that the Java method System.nanoTime() may also return the same information, for pure Java apps. So going native might not even be necessary to pull off a cache-timing attack on Android.

Also, there can be other accurate clocks. For instance, the GPS API provides one, with Location.getElapsedRealtimeNanos().

Side-channel attacks on cache access have been demonstrated on common AES implementations (in lab conditions, but still demonstrated). There has been quite some work done on such attacks against cryptographic algorithm, but there is nothing here really specific to cryptography. It just happens that cryptographic algorithms uses keys and keys concentrate secrets; knowing the key reveals a lot of things, so keys are high-value targets. Also, all such attacks were researched by cryptographers, and cryptographers work on cryptographic algorithm. However, side-channel leaks may occur on just every single implementation of any algorithm, cryptographic or not. Usually, when encryption occurs in a device, it is because some confidential data is processed by that device, and all that processing, not just the encryption, may leak like crazy. The issue is real and all-encompassing.

Under these assumptions, one must assume that a lot of data can be inferred from an app, about what other apps do. Defending against local attackers, who run their code on the same hardware as you and at the same time, is hard.

  • (I think I got it wrong between clock precision and clock accuracy. It does not matter, for the attack, that the clock matches some atomic clock in Geneva, because only time differences are needed. One must be able to see the effect of a cache miss, though, and that's about 50 or 100 nanoseconds.) – Tom Leek Sep 13 '13 at 13:49

Lots. I don't propose to give an exhaustive list, just a few representative examples.

can app M learn what IP addresses app A is communicating with?

Yes, even with its eyes closed and both hands tied behind its back. /proc/net/tcp lists all open TCP connections. Here's me. On Android, the uid reveals the application; the same information for a given process is available to all in /proc/$pid/net/tcp.

shell@android:/ $ cat /proc/net/tcp                                            
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 3600030A:AF4C 10CEFCC6:0050 01 00000000:00000000 00:00000000 00000000 10004        0 402734 1 00000000 37 3 8 10 -1                            

Can app M learn whether app A is currently using some exclusive-access resource/sensor (e.g., the microphone, the camera, etc.)?

If the resource is exclusive-access then app M can at least poll to see whether the resource is in use. M can correllate this information with app A's activity statistics in /proc/$pid/stat*.

Can app M infer anything about text being typed into app A through the on-screen soft keyboard?

Yes. Smartphones have a lot of input devices: camera, microphone, accelerometer, … With the accelerometer alone,

In controlled settings, our prediction model can on average classify the PIN entered 43% of the time and pattern 73% of the time within 5 attempts when selecting from a test set of 50 PINs and 50 patterns. In uncontrolled settings, while users are walking, our model can still classify 20% of the PINs and 40% of the patterns within 5 attempts.

That success rate is only among 50 random PINs and the success rate at deciding between 1974 and 1975 would probably be lower. On the other hand, this study was using the accelerometer alone, and combining other data such as camera and timing would probably improve the rate.

Timing measures can leak a lot of data; see Tom Leek's answer.

The information that comes through /proc is specific to Android; other operating systems may or may not expose this information. Something like SEAndroid could prevent this information from leaking to other applications. On the other hand, the side channel issues cannot be escaped simply by better dataflow isolation. They require eliminating useful features such as the ability to tell the time or to access hardware devices while another application is executing, which might be acceptable in some settings (e.g. smartcards) but not in a smartphone.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.