There should be some very basic safeguards to help users discern what is “real” in the UI:
1. Every user should be able to select a custom color and pattern, e.g. to display around the border of system UI. This should be stored in such a fashion that an app can’t simply “guess” what color/pattern to show in a fake UI.
2. Part of the “set up new device” overview for all new users should be to remind them what the UI is supposed to look like.
3. For crying out loud can we move away from these simplistic, ugly UIs. I’m tired of looking at unimaginative colored rectangles on machines capable of displaying cool, photo-realistic artwork. Make Google/Apple/etc. hire entire teams of hundreds of artists to create cool, extremely-difficult-to-render UIs with beautiful buttons, etc. and then bad actors won’t be able to just hack together a real-looking UI in 5 minutes.
> For crying out loud can we move away from these simplistic, ugly UIs. I’m tired of looking at unimaginative colored rectangles on machines capable of displaying cool, photo-realistic artwork. Make Google/Apple/etc. hire entire teams of hundreds of artists to create cool, extremely-difficult-to-render UIs with beautiful buttons, etc. and then bad actors won’t be able to just hack together a real-looking UI in 5 minutes.
While I agree that today's phone UIs are boring, I don't think replacing them with photorealistic, "extremely-difficult-to-render" UIs is a good idea -- nor would that protect against imitation by malicious app publishers.
Usability would go straight out the window. Every menu in every app would become an assault on the eyes, or at least an incredible nuisance. UI elements should be clear and consistent, and should stay out of the way.
There are lots of ways to render beautiful, unobtrusive UIs that are difficult to emulate. For instance, a Retina-detail polished metal button would be readable and look good but it would be non-trivial to recreate (unlike our current login dialogs that could practically be recreated in MS Paint). It would be especially secure if it included personal information, e.g. an etched-in-metal appearance of your full name.
Apple doesn't support overdraw across apps, but there are still things Apple can learn here. Many system apps still use "insecure" dialogs that can (and are!) used to train users to do unsafe things. This[1] dialog can be drawn by an app (or injected using an advertisement!), and Apple ID failures are "common enough" that this works to collect people's Apple IDs.
The "draw on top" hole is a known issue on Android that iOS does not share (since you can't do that on iOS afaik).
Google has several time been tempted to just remove it but since many have legitimate use cases for it that are very popular (like facebook messaging bubble), it has been not been removed fully.
Like it is mentioned in the talk, you need the 'draw on top' permission to do so. The caveat is that apps downloaded from the play store get it by default.
From what I have seen, the talk seem to only talk about the doability of such an attack, not that it has been seen in the wild ?
In theory, you could craft an app with a legitimate draw on top behavior + the malware one and get it published that way. The approval/rejection on the play store is very obscure though, so hard to get any more info on that.
IIRC, Google has also added a "an app is drawing on top of the screen" permanent notification when an app does so, causing many people to be pissed at this 'useless' notification. ffs.
iOS does have a11y capabilities as well, so there is that surface of attack, although I don't know if it is exploited.
I'm assuming the draw on top is through a specific API right?
Why not have a section for (if you do use the feature) justifying why you need draw on top. Then have someone go over the source code to verify that the information volunteered matches up with what is going on behind the scenes. Or just decrypt APK and search for usages of the library?
Also, why is such an intrusive feature enabled by default?! I want proper prompts explaining why they want it, and to be able to decide if I want to give them those permissions.
That someone is who exactly? Did you ever try to contact support for any google product and get more than some standard text blocks back? And that's just regular support people. For what you suggest you'd need an army of people literate in Java, reviewing any app with that permission, including every update, ever uploaded to the app store.
The best way would be to just get rid of this feature, and then maybe look at what the most common use cases for it were and add a few APIs for those.
Now I remember that part. It is not exactly a public API.
As I remember it, what it actually is is a permission to show system window. Its original intent is to allow apps to show dialogs. I am not sure it was even intended to be used by third party apps..
But in the old android days, if you declare for a permission in the manifest and the user gives it at install time, you have it (there were already some forbidden permission, but this was not one of them).
When Google started revising the Android permission system, this one must have been a thorny problem. It was not supposed to be used by third party apps but there were 'legitimate' use cases, like the facebook messenger and its bubble.
One of the beta versions after Marshmallow started treating this permission very carefully with warnings around it. There was a very noisy part of the testers up in arms against that idea. "How dare you remove a feature that I use (even though it is a hack and a dangerous one) ?" So instead it looks like they were very cautious in how to handle this change.
Fwiw, the play store security team is way more active that the FUD says .. and it does not look like there is any know exploitation of draw on top in the wild. Maybe they do indeed analyze the code of apps using draw on top. Maybe the combination of having to only incorporate a hack based on draw on top on apps served on the play store and the increased scrutiny that goes with it make it unattractive to malware creators ?
To be honest, I fail to see why draw on top is so important. The most I have ever used it is with apps like https://play.google.com/store/apps/details?id=com.actinarium.... to draw a grid on top of the system. It could easily become a library instead (and there are already some).
I would be all in favor of just removing it, or making it another runtime permission. I am not even sure that runtime permissions work that well, on iOS or Android. Most people I know have just been conditioned to tap 'yes' on all dialogs.
A lot of this is not possible in iOS, because it doesn’t allow drawing on top of alert type messages. The attacks relating to password managers are probably still relevant. Possibly so are the ones relating to accessibility, although I don’t think iOS allows accessibility controls access like Android does.
* In some very specific cases apps can "draw" on top of other apps, namely though the "app extension" mechanism which is completely out-of-process and very tightly controlled (for example, apps have very limited ability to modify the context outside of the "rectangle" they render in).
I believe it's demonstrating accessibility attacks (though, I don't have the audio myself so I could be wrong). In the first case it looks like the password text field is blocked so accessibility is used to grab the code while the user types it in, in the second a two-factor code is pulled from the Authenticator app, and in the last the phone's passcode is recorded as the user types it in?
Edit: watched the video of the talk linked above; the above descriptions seem to be accurate
And/or https://youtu.be/FRpcGwCedZ0