Researchers Hack Gmail With 92 Percent Success Rate 87
A reader sends this report from CNET:
Researchers at the University of California Riverside Bourns College of Engineering and the University of Michigan have identified a weakness they believe to exist across Android, Windows, and iOS operating systems that could allow malicious apps to obtain personal information. Although it was tested only on an Android phone, the team believes that the method could be used across all three operating systems because all three share a similar feature: all apps can access a mobile device's shared memory. "The assumption has always been that these apps can't interfere with each other easily," said Zhiyun Qian, an associate professor at UC Riverside. "We show that assumption is not correct and one app can in fact significantly impact another and result in harmful consequences for the user." To demonstrate the method of attack, first a user must download an app that appears benign, such as a wallpaper, but actually contains malicious code. Once installed, the researchers can use it to access the shared memory statistics of any process (PDF), which doesn't require any special privileges.
Oh sure (Score:3, Informative)
Just because Android is flawed doesn't mean that iOS and Windows are flawed too.
tl;dr (Score:5, Informative)
Despite what the summary implies none of this is about actually reading memory in use by friendly apps. i.e. until the user gives the hostile app his account information the app knows nothing. All in all not a particularly powerful attack vector.
Re:Blast from the past (Score:5, Informative)
Blocking access to the memory space of other processes has been a solved problem since timesharing in the '60s and '70s, right?
Sure it was. That isn't what is happening though.
Its not accessing the apps memory itself. Its accessing the shared memory *statistics* of a process.
Then its using pre-calculated patterns of the shared memory usage (presumably allocation order, sizes allocated, NOT the actual memory contents etc) to guess what the user is doing in the other app. Then, when it detects a pattern that corresponds with "I'm about to log in" it pre-empts the app with its own phishing login screen skinned to look like the original. The user is -expecting- a login screen to popup, and one that looks right does... so they enter their credentials.
I assume they...
All your assumptions and proposed solutions were completely wrong.
The solutions are:
a) to remove untrusted apps ability to monitor memory USAGE statstics
b) to remove untrusted apps ability to pre-empt the screen.
c) better permissions controls and better CURATION limiting
d) it may also help to let apps enter 'critical sections' that cannot be preempted by other apps (?)
summary (Score:5, Informative)
basically, a well-timed phishing attack.
1. in android, you can detect when the UI state changes (a new activity, or screen is brought to the foreground) by looking into a shared memory channel. this tells you nothing else other than that the UI state has changed.
2. you can build a "fingerprint" of a particular UI state change based on CPU utilization, network activity, process list, or possibly other things when the state change occurs. you can use this, plus #1 to know when *specific* UI state changes are occurring.
3. if you have managed to get a malicious app installed, and you know when a specific UI state change is occurring, the malicious app can impersonate the real UI state change, fooling the user into entering sensitive information.
Not on iOS (Score:5, Informative)
Apps on iOS can't inject a dialog over top of another app, or even bring their own app to the foreground programatically, so this is not even possible on iOS. Maybe the app could monitor for actions, but it can't do anything with that info.
not reading memory, just see HOW MUCH shared memor (Score:5, Informative)
Android DOES run each app as a separate user, and one app cannot read another app's memory.
Processes have private memory and shared memory. Shared memory is used for communicating with other processes, such as the window manager.
An app can tell HOW MUCH shared memory another app is using. You see this in task manager, it'll tell you that your browser is using 12 MB of shared RAM or however much.
So the attack goes like this:
On their own device, the attacker monitors how much shared memory is being used by the Paypal app and the eBay app.
The they "pay now". The eBay app opens a "login to PayPal " window.
To display the window, the eBay app must communicate with the OS or window manager.
The attacker notes that when the app displays the login window, the amount of shared memory used increases by 26KB.
The attacker builds an app the monitors the amount of shared memory in use.
If the amount of memory in use jumps by exactly 26KB, that's probably because the "login to PayPal " window in being displayed.
The malicious app pops up it's own login window on screen, which looks just like the PayPal login window.
The user was expecting a PayPal login window, they see what looks-like a PayPal login window.
The user enters their PayPal credentials.
This is all based on knowing HOW MUCH memory is used vs available. From that, you can infer whwn another app opens a new window (activity).
Re:tl;dr (Score:4, Informative)
Its a very powerful attack vector
Yes and no.
I'd like to point out that the authors have only used the attack on Galaxy S3 devices running Android 4.2, for a very specific set of apps.
"We run all experiments on Samsung Galaxy S3 devices with Android 4.2. We do not make use of any device-specific features and expect our findings to apply to other Android phones."
Basically, they use the following (world-readable) elements to generate signatures of certain Activities (parts of apps) starting up.:
- CPU usage pattern
- Network usage pattern
- Increase and decrease of the shared memory (where the graphics buffer of the window compositor resides)
(they use more elements, but these are their most important ones: "Thus, the CPU utilization time, the network event and the transition model are the threemost important contributors to the final accuracy. Note that though the Content Provider and input method features have lower contributions, we find that the top 2 and top 3 candidates’ accuracies benefit more from them. This is because they are more stable features, and greatly reduce the cases with extremely poor results due to the high variance in the CPU utilization time and the network features.")
For the apps mentioned, they collect this data for a large number of the same Activities starting up. They average the results (model it using a normal distribution) and use that data as input for an offline machine learning step in which a model is generated.
On the 'hacked' device itself, they can then use the live data in their classifier and predict which Activity is starting up. When a specific target Activity is started up, they immediately start up their own mockup Activity and destroy it after the data has been entered, returning the user to the previous Activity with a misleading 'Server error' dialog in between. This method is what allows the injection to work without requiring the 'draw over other apps'-permission.
Now, anyone who has experience with machine learning can see how these results may not generalise very well, given that they used only a specific set of apps on a specific device. Choosing between 100 alternative Activities is a lot easier than choosing between the millions of Activities out there. How many signature collisions (false positives) would that lead to? A lot.
That is exacerbated by the fact that different users run different sets of apps in the background, which obviously greatly influences the CPU usage signatures and network signatures.
Besides that, the signatures are device and probably Android version specific, leading a model for many devices to become prohibitively large to be distributed in a single app. Of course, this can be mitigated by just targeting one specific very popular device (such as one of the Samsung flagship models).
Their injection of the activity is also something to look at again. Consider this:
"Note that the challenge here is that this introduces a race condition where the injected phishing Activity might enter the foreground too early or too late, causing visual disruption (e.g., broken animation). With carefully designed timing, we prepare the injection at the perfect time without any human-observable glitches during the transition (see video demos [6])."
Everybody knows that 'carefully designed timing' and generalisable match very poorly. Targeting one specific device may indeed work here, but I think some testing in more varied scenarios is required before we all shit our pants.
they all use memory. If app can check available me (Score:5, Informative)
If an app can see how much memory is available, it can use this technique. All operating systems use memory when they create a new window and when the create gui widgets such as input fields and buttons.
On their own machine , the malware author monitors free memory vs used memory. The click "buy now" in the eBay app. That open a "log in to PayPal " window. The malware author notes that opening the login window caused memory usage to increase by 23752 bytes.
The malware author creates an app that monitors how much memory is used. When memory usage jumps by exactly 23752 bytes, that means the PayPal login window is probably being opened. The malicious app pops up it's own window that looks like the PayPal login window. Since the user was expecting a PayPal login window at that moment, they enter their credentials. 5. Profit!
Note there's nothing unique to any operating system here. On any systwm, an application can find out how much memory and disk space is available, and therefore infer whether or not the PayPal login window is being opened, based on the precise amount of memory that window uses as it opens.
Re:they all use memory. If app can check available (Score:1, Informative)
But on iOS another application cannot bring itself to the foreground over another app.