7 ms·

Betrayed by the Android UI [slides]

159 points by PieUser 8y ago

walty8 8y ago
Just curious, is this restricted to Android only?
- gbear605 8y ago
  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.
  - closeparen 8y ago
    iOS doesn't allow apps to draw over other apps at all, AFAIK.
    - saagarjha 8y ago
      * 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).
  - chii 8y ago
    So the question is whether the trade-off of accessibility capabilities worth the decrease in security?
    - henvic 8y ago
      In general terms, iOS accessibility is far greater than Android's. I would say this is more akin to a feature than accessibility, in practical means...
      - saagarjha 8y ago
        iOS does accessibility natively and does not allow apps access to it to the extent that Android does, AFAIK.
- on_and_off 8y ago
  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.
  - sk0g 8y ago
    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.
    - iforgotpassword 8y ago
      > Then have someone go over the source code 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.
    - 8y ago
- geocar 8y ago
  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. [1]: https://i.imgur.com/85aeL4H.png https://i.imgur.com/85aeL4H.png
rovyko 8y ago
Interesting slides, I wish we could hear the presentation audio. What's going on in slide 22?
- saagarjha 8y ago
  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
- c8g 8y ago
  https://news.ycombinator.com/item?id=19474818 https://news.ycombinator.com/item?id=19474818
cheesedoodle 8y ago
Talk: https://youtu.be/BmXaMaxx7OY https://youtu.be/BmXaMaxx7OY And/or https://youtu.be/FRpcGwCedZ0 https://youtu.be/FRpcGwCedZ0
i386 8y ago
Slide decks like that make me happy that Apple make developers jump through a few extra constraints and approval loops.
- on_and_off 8y ago
  I have been working on both platform for a while. Sorry but I don't believe the App Store approval process make any difference in that regard. Apple does make your app run in a sandbox to try to detect known malware, just like Google does for the play store. As for the other parts of the review process, 99% of why they are here seem to be to protect's Apple interests (cf spotify).
  - saagarjha 8y ago
    App Store review isn't great, but iOS's implementation of these APIs (or lack thereof) are very effective.
Markoff 8y ago
why is this not available as static webpage? it's difficult to read as slides
- BLanen 8y ago
  Or just a pdf.
  - rahimnathwani 8y ago
    You can download it as a PDF here (File -> Download as -> PDF): https://docs.google.com/presentation/d/1Ya2BThnbkXzAtXR3zh9SAiLAZ_mC3nYt8Zxm-KAIqZ4/edit#slide=id.p https://docs.google.com/presentation/d/1Ya2BThnbkXzAtXR3zh9S...
makecheck 8y ago
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.
- EForEndeavour 8y ago
  > 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.
  - makecheck 8y ago
    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.
rqs 8y ago
Slide 17: Google: Hey so we had this new thing called FLAG_WINDOW_IS_OBSCURED Me: Really? Google? You're going to fix your problem by telling everybody to watch out your problems?

159 points by PieUser 8y ago

walty8 8y ago

Just curious, is this restricted to Android only?

gbear605 8y ago
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.
- closeparen 8y ago
  iOS doesn't allow apps to draw over other apps at all, AFAIK.
  - saagarjha 8y ago
    * 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).
- chii 8y ago
  So the question is whether the trade-off of accessibility capabilities worth the decrease in security?
  - henvic 8y ago
    In general terms, iOS accessibility is far greater than Android's. I would say this is more akin to a feature than accessibility, in practical means...
    - saagarjha 8y ago
      iOS does accessibility natively and does not allow apps access to it to the extent that Android does, AFAIK.
on_and_off 8y ago
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.
- sk0g 8y ago
  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.
  - iforgotpassword 8y ago
    > Then have someone go over the source code 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.
  - 8y ago
geocar 8y ago
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. [1]: https://i.imgur.com/85aeL4H.png https://i.imgur.com/85aeL4H.png

rovyko 8y ago

Interesting slides, I wish we could hear the presentation audio. What's going on in slide 22?

saagarjha 8y ago
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
c8g 8y ago
https://news.ycombinator.com/item?id=19474818 https://news.ycombinator.com/item?id=19474818

cheesedoodle 8y ago

Talk: https://youtu.be/BmXaMaxx7OY https://youtu.be/BmXaMaxx7OY And/or https://youtu.be/FRpcGwCedZ0 https://youtu.be/FRpcGwCedZ0

i386 8y ago

Slide decks like that make me happy that Apple make developers jump through a few extra constraints and approval loops.

on_and_off 8y ago
I have been working on both platform for a while. Sorry but I don't believe the App Store approval process make any difference in that regard. Apple does make your app run in a sandbox to try to detect known malware, just like Google does for the play store. As for the other parts of the review process, 99% of why they are here seem to be to protect's Apple interests (cf spotify).
- saagarjha 8y ago
  App Store review isn't great, but iOS's implementation of these APIs (or lack thereof) are very effective.

Markoff 8y ago

why is this not available as static webpage? it's difficult to read as slides

BLanen 8y ago
Or just a pdf.
- rahimnathwani 8y ago
  You can download it as a PDF here (File -> Download as -> PDF): https://docs.google.com/presentation/d/1Ya2BThnbkXzAtXR3zh9SAiLAZ_mC3nYt8Zxm-KAIqZ4/edit#slide=id.p https://docs.google.com/presentation/d/1Ya2BThnbkXzAtXR3zh9S...

makecheck 8y ago

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.

EForEndeavour 8y ago
> 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.
- makecheck 8y ago
  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.

rqs 8y ago

Slide 17: Google: Hey so we had this new thing called FLAG_WINDOW_IS_OBSCURED Me: Really? Google? You're going to fix your problem by telling everybody to watch out your problems?