> Meanwhile, temporary exceptions will be granted to dedicated banking and digital wallet apps so that they can “obtain broad visibility into installed apps solely for security based purposes.”
I'm sorry but why does a banking app need to see a list of system-wide packages? And for what security-purpose? If all apps were tightly sandboxed in the first place then this wouldn't be a problem that requires edge-case solutions.
Either way, based on the same quoted paragraph, my prediction is that Facebook will now roll out a dedicated wallet app; along with regular wallet functionality it will gleefully take advantage of this exact loophole.
Banking apps sometimes integrate 3rd party AV / threat detection SDKs (there are several available, e.g. https://www.wultra.com/malwarelytics which is part of a bigger banking security SDK solution). Sandboxing isn't the only problem on Android - a lot of malware is using Accessibility to control the device and read what's on your screen. Then there are overlays that can be drawn over your app (e.g. display a fake login over your app). Access to notification content. Reading SMS content (2FA). Different combinations of other permissions, device manager rights etc. Or even simple attacks like launching a fake app just when you launch the real one (phishing). Google is trying to limit a lot of these permissions, at least from apps installed from Google Play but so far they are still pretty widespread with malware hidden on Google Play targeting banking apps.
3rd party AV sdks? This reeks of snake oil. They should just stop treating the device as a hardware security anchor.
And how is it still ok that most android phones in the wild do not get security upgrades, let alone timely ones?
The tricky part IMHO is that with safetynet google is selling snake oil themselves. If they are claiming that security does not count as fair use to spy on the userfor others, ... .As much as I like security awareness. In the end it means patronizing users in order to control the ecosystem. The problem with banking and google is that we cannot escape this ecosystem without losing a lot of commodity. Why not do it like Apple and put annoying popups before each install process if apps want spying permissions. The only reason can be that google wants us to not be aware...
My supermarket's loyalty app refuses to run on rooted devices, I imagine they are using something like this to detect if the device is rooted (e.g. looking for Magisk). It makes no sense, because all it does is show what offers are available that week (which you can also see on their website) and provide the same QR code that is on the physical card. I imagine some PM at whatever agency they used decided they wanted to make it secure (and upsell that to the client), and installed some nonsense SDK like this.
My bank's app have no issues with my phone being rooted :-) Fortunately Magisk Hide fixes it.
Big business means it would've been defeated or just completely worked around - truth is that if you're doing this at scale you'd just reverse engineer how the application talks to the backend and replicate that in your software.
Just like DRM, it inconveniences legitimate use while doing little to defend against malicious use.
I don't believe this is the only reason. If it were, they would be blocking logins through mobile web browsers since there's no JavaScript API that dumps the list of installed apps. All those same attack vectors could exist on top of the users web browser as far as I know.
They don't have to block the login completely but they may treat it as less trusted and require additional authorization for, say, an outgoing wire transfer. Of course, this assumes banks are doing actual risk modeling not just security theater.
Can't they do this for apps too? Treat them as "less trusted", instead of doing all that bullshit with shipping bundled scanners, and the insane policies that make it impossible for me to take a screenshot of transaction details in the app...
(Yes, I know. My role as a user isn't to have opinions - it's to dutifully enjoy the software as-is, and visit the "offers" section on a regular basis.)
I don't think so - or if they do, then the functionality won't be very effective. A lot of the most common attack vectors have never existed in iOS. Applications on iOS can't draw over other apps, you can't implement your own accessibility service, you can't launch apps from the background without user interaction, you can't install apps outside of the App Store, you can't run a service in the background for unlimited time, you can't implement your own keyboard (key logger), or read SMS messages, notifications, system events and a lot of other things have never been accessible to developers on iOS. I haven't heard about banking malware on iOS. But on Android you can find hundreds of examples and even right now there are several circulating on Google Play. The openness of Android OS has advantages and disadvantages, but Google has been heavily limiting most of these options recently.
Google already allows online banking apps to block screenshot functionality, which is in my opinion total bullshit. The owner/user of a device should always be able to take a screenshot if they want. At least every bank has a market based need to allow regular browsers to sign in to online banking, to support desktop clients, so one can just ignore the provided bank's app if you want.
It's to prevent malicious applications taking a screenshot of sensitive information. I've seen other apps doing this on, for example, credit card info entry screens.
It wasn't a banking app, but I recently came across the first app I've seen that, in addition to SafetyNet, also checked if the Magisk Manager app was installed to try to detect if the phone was rooted. I wouldn't be surprised if it was for this purpose.
Computers are compromised all the time and but so far as I know banking at insertbankhere.com doesn't involve giving your browser tab root privileges on your machine in order to run its own antivirus. It's an improper separation of concerns.
Your bank also doesn't concern itself with the type of locks on your door or your car alarm. Just because something gives someone a handle on matters like the ability to see what apps are installed on your device doesn't mean its appropriate to use it.
Not allowing the bank app inappropriate access to your device means they aren't tempted to leak or misuse it.
I find it hilarious how Play Store is slowly banning permissions (some justified, some not) in regards to 'privacy', yet the internet permission is still classified as a low dangerous permission [0], which means that when you install an app, this permission is not even shown. (And you can't even turn it off!)
The Internet permission was largely useless. If you knew what you were doing, it was trivial to bypass it to exfiltrate data. On top of that, almost every app requests it, which contributed to alarm fatigue in users.
Permissions are only useful if they can be enforced and users pay attention to them.
For relatively small bits of info, probably only once before the app is uninstalled: yep, agreed, this works. There's no practical way to prevent it either, short of requiring interaction literally all the time, which just makes dialog-fatigue worse.
But ultimately this will do a single extremely visible GET request, which is limited by the browser's normal sandboxing. That's quite far from "bypassing the internet permission". And in some cases ineffective (e.g. I have multiple browsers and intentionally do not set a default), though that's rare enough that I don't think it's relevant.
---
An "app can send intents" permission would be sorta nice for things I truly want sandboxed, e.g. a password manager. XPrivacy allow(ed|s) blocking stuff like this, I would and did happily toggle it off for most apps since e.g. many games have no need of anything but their APK's data.
Run a local vpn like netguard! https://netguard.me/ I leave mine on deny by default.
That said, I completely agree. Google's approach to permissions on Android has been wildly user-hostile, and full of nonsense bundling like (relatively harmless) device-ID and (very much not) access to all call logs. Stuff like XPrivacy[1] demonstrates how they could have done this with far more user control and far less app interruption, but they haven't.
[1]: not the UI, the UI is terrible. but "send fake contacts" or "block outright" for every API is excellent, and doesn't require changing apps to support. the fact that the apps can query the state and I cannot lie about it is a problem, because they often require lots of bullshit that's not required.
There's a balancing act. Historically Android would just provide a list of what permissions each app wants, and you either take it or leave it. That's transparent in a sense, if researchers care they can do the analysis and produce a paper, "Hey, 80% of the top X apps request permission Y which they have no Earthly reason to need" - but almost no end users will read this boring technical stuff to make decisions. See also pre-Baseline Requirements "class based" X.509 certificates. Adding more permissions to this list is easy... but also has almost no effect. There's a good chance you've never looked at the permissions you granted most apps you have.
In the modern era some of these abilities also require an explicit grant of permission when used. Location is an example we've all seen.
But that incurs fatigue so it has to be used cautiously. For example Android could ask if apps are allowed to use the Network, but you'd likely get sick of that really quickly, so instead you can explicitly disable network access for an app if you want, but it doesn't ask "Can Daily-quiz-app-1234 access the network?" when you run it.
One option Google has that's more extreme than a fatigue-inducing prompt, is to just refuse permission anyway, which is what's happening here.
And unlike iOS, an Android phone can run other browsers, but for a modern browser on a nice phone you want WebAuthn. If any app can just say "I'm actually a web browser" then WebAuthn's phishing protection blows away when you install some Flappy Bird clone to try it out - the app just tells the OS it's a web browser, comes up with some excuse as to why you should touch your fingerprint sensor, and it says to the OS it's browsing https://your-bank.example/ so it gets credentials for your bank. So in this case Google manages some high risk permissions only for known safe developers. Mozilla's public Firefox builds have this "I'm really a web browser, I get to do WebAuthn" permission, but if you build the exact same source and sideload it, it can't do WebAuthn.
[Apps all get the same, likewise unphishable, feature on capable phones, Android or iOS, but without this "web browser" permission it's fixed so that they can't ask for credentials for a web site, only for their own app]
> There's a balancing act. Historically Android would just provide a list of what permissions each app wants
That's one of the many design choices that made truly filthy apps possible on Android. I worked on a device monitoring(wink) app back in the day(which I'm not proud of). The things we did there...Installing apps without an app store, hiding application icon(!), recording phone calls(!!!), reading messages(!!!). And all of that was done using official APIs on a non-rooted device.
Permissions are something I wish desktop os’s would adopt. In most systems, any rando application I run has access to every computer resource that I as a user have access too! Depending on the system, this could mean: my personal documents, my desktop folder, my downloads, all attached peripherals, including microphones and cameras, serial and parallel ports, any radios including WiFi and Bluetooth, the network, a list of running processes, a list of installed applications, the clipboard, and on and on. Why on earth should this be the default? As a user, I should be able to easily deny any application access to these things.
This made a little sense when you could trust application developers with access to all these things, but that ship has long since sailed.
Why would access to the fingerprint sensor give the ability to forge WebAuthn signatures? An app being able to detect that the phone’s user has their finger on the sensor does not in any way compromise the security of a different app doing the same thing.
Obviously one could write a malicious browser that implements WebAuthn wrong and compromises users who register with a site using that browser. This leads to discussions about WebAuthn attestation, and there are valid arguments there both ways.
> Why would access to the fingerprint sensor give the ability to forge WebAuthn signatures?
It wouldn't? No apps get access to the fingerprint sensor, it's very hard to imagine any legitimate purpose for that, and easy to imagine hostile use cases.
The operating system doesn't give access to the fingerprint sensor, it provides an API for doing FIDO (the underlying technology to deliver WebAuthn) and the fingerprint sensor is used by the operating system to provide User Verification for that.
The API takes a parameter for the Relying Party Identifier. For most phone apps, you can't control this, it'll be set to an ID for your app, which you can discover and fill out in your server backend. This way your app can authenticate your users to your servers, but other apps can't imitate it.
But for WebAuthn the RPID is based on the DNS name of the web site, so a web browser needs a way to actually set this value or it can't do WebAuthn. Hence, Android needs an extra permission flag to authorise legitimate web browsers to set the RPID while preventing untrustworthy apps from doing so.
This sounds like a mediocre design. An entirely separate key hierarchy per app would avoid any possibility of confusion signatures with those generated by another app, even if both apps were web browsers.
> so instead you can explicitly disable network access for an app if you want
Some OEMs provide this feature in their firmware, but many/most do not. Users have to resort to running local VPNs like NetGuard. Even ADB can't do it: "Permission android.permission.INTERNET requested by com.android.vending is not a changeable permission type". If you know a way, please share!
I understand permission fatigue but this lack of control is, to me, blatantly user-hostile.
"Google is limiting what apps can use the QUERY_ALL_PACKAGES permission that “gives visibility into the inventory of installed apps on a given device.” "
Sounds like it already is. Google Play is simply changing its policy on which apps may request that permission.
Because that capability is required for apps to interoperate. Sandboxing by definition breaks the ability for apps to share data and work together. It's a balance to be struck, a perfectly secure system is a useless system.
In this case it was mostly used to render custom share dialogs (you need to list apps for that), in-line share buttons (checking if other app exists is useful to not show the ones that aren't installed) and some other possible optimizations (e.g. mostly bug fixes for broken apps that couldn't handle types of data).
From developers perspective it's useful because it makes your app more reliable and easy to use. With the downside that malicious people can abuse it.
I see absolutely no reason for this. You want to share a picture? Fine! Just specify a content type, and the system will present a list of apps capable of handling it to the user.
Sharing pictures isn't the only use case. The APIs were widely used for quite a few other use-cases as well (this is why it's a permission now and not removed completely).
Please remember that but everyone subscribes to your exact model of safety and capability. There are people that want more from their pocket computers than a restricted consumer device.
IMO internet access (android.permission.INTERNET) needs to be a runtime permission. Ideally with the same kind of granularity as location — one time, while app is in use, in the background (through settings). And give an app a brief window to access the internet after an FCM push, but FCM pushes are also a runtime permission.
But Google being an advertising company would, of course, never ever do this.
This means that nearly every application will have a pop up which nearly every user will get so used to seeing that they'll almost always just press "allow" on, which will mean permission prompts become less useful and security gets worse.
IIRC part of the problem is that there are other leaks through the intent system. So the system is so broken that adding a permission for INTERNET would just be an illusion of safety.
What do you mean? If you don't have the INTERNET permission in your manifest, you won't be able to create network sockets. So this enforcement is already in place, it has always been. The only possibility I see of leaking internet access through the intent system is when an app that does have internet access would give content:// URIs with granted URI permissions to an app that does not, so it would indirectly and unknowingly download something from the internet through that app's content provider. I don't think it's possible to grant anything on an http(s) URI. For that matter, almost any permission can be "leaked" this way. You could even skip the intents and content providers and just do it with straight AIDL if you're so inclined.
Android's permission system is pretty solid and almost impossible to work around.
The point of removing the INTERNET permission as I see it is to prevent the app from sending out any information, allowing you to trust it with your sensitive information. However if the app can raise an intent that will cause another app to send out information of its choosing it has effectively broken that permission, even if it never created a socket. Sure, the app may have a hard time getting information back (although there are channels such as app updates at the very least) it isn't enough to trust an app with your passwords just because it doesn't have any permissions.
It's great for security, but also great for Google.
OS and their frameworks still get full visibility into apps, and given how much data they collect, it's cutting off this data (rightly) from others, and keeping it only for themselves (both for good and bad reasons).
TIL apps on Android can see what I have on my device. Is iOS the same way? That is pretty abhorrent. You can tell a lot about a person looking at what apps they have installed.
On iOS apps can check for the availability of URL schemes ("can I open a link of type ftp:"), so they can check if apps that expose a URL scheme are installed (mostly this is apps that offer an API, such as Facebook, Twitter, etc).
But, apps have to declare which URL schemes they want to be able to check for, and this list is inspected by app review. So if you want to check for every known app in existence (which some apps like IIRC Twitter used to do before Apple limited it), you'll fail app review. I'm not sure how strict they are about shorter but weirder lists of URL schemes (like a todo app checking for bank apps)
TIL that my bank app on my A10 device has permissions like change your audio settings, view wifi connections, prevent phone from sleeping, run at start up, control vibration, access extra location information...
And there is no user interface to revoke or manage these permissions. What the heck!
is there any way to broadcast or make known that there is an Intent handler registered?
im wondering if apps have the capability to signal to each other that they exist. it's been so long since I've touched android, but I remember Intents were often the main sort of rpc engine across apps. Even if apps can't ambient survey the system now, I'm wondering if they can still make smoke smoke signals to each other.
I'm sorry but why does a banking app need to see a list of system-wide packages? And for what security-purpose? If all apps were tightly sandboxed in the first place then this wouldn't be a problem that requires edge-case solutions.
Either way, based on the same quoted paragraph, my prediction is that Facebook will now roll out a dedicated wallet app; along with regular wallet functionality it will gleefully take advantage of this exact loophole.