Droppers Is How Android Malware Keeps Sneaking into the Play Store
bleepingcomputer.com
bleepingcomputer.com
Why not just allow them to disable specific perms on install and provide stubbed generic data to the app if it uses those perms?
Wouldn't it make sense to have temporary permissions? In Linux and Windows you have to sudo/admin also for one single action or a set of actions. You don't give a program access rights for eternity.
Maybe I want to use some app's location service only very rarely and I fear that it has some surveillance features integrated. If I'm ok sharing my location right now, I might not be ok sharing it always. It would be good to have the ability to give it the permission once, until a system restart, or for a limited timeframe.
The systems which provided generic data worked very well a lot of the time, but also some of the time would just subtly break things in a way which was not obvious for a non-technical user.
Is this available via a non-root API? There are those blackmailing applications that refuse to do their core functionality when a certain unrelated permission is denied (the hell you need my location, music streaming app!). If Android fed them generic data, they would quickly learn to detect it - but not if data is controlled by other Apps or the user himself.
Imaging a messaging app. It needs permission to read and write to your text messages - not so bad.
Maybe there's a feature where you can quick-reply from the message notification. Now it needs permission to draw over other apps.
Maybe it's smart enough to not DING! during a phone call. Now it needs permission to "make and manage phone calls".
Maybe there's a feature where it suggests a "here's my location" response when somebody texts you "where are you?". Now it needs permission to access your location.
Contact integration? Camera integration? Access storage? These are all things that a messaging app might reasonably want to do. But seeing a big list of permissions, including things like "draw over other apps" and "make and manage phone calls" is scary to an end user. Especially for an app that's only supposed to be handling SMS.
OSes should allow me to create a sandbox for an app, so I can grant them access (and the app will not "break"), while still being secure.
Android should add the option for temporary data access. I would prefer turning on the access temporarily to send 1 photo, then turning it off a few minutes later.
https://developer.android.com/training/articles/security-tip...
See: https://developer.android.com/reference/android/Manifest.per...
If you don't mind sharing, what app are you referring to?
The file system itself should be well protected (on a non-rooted phone) as to prevent any unauthorized access to important data. Any app can only do whatever on the SD card if you give it permission to do so, but on the OS file system itself there isn't much they can do (again, on a non-rooted phone).
https://developer.android.com/training/secure-file-sharing/r...
If a photo management app needs access to your photos, you should be able to give it access to your photo library.
A better solution (imho) is to make the app think it has access, while in reality its access is limited to a sandbox.
Linux can also allow limited access to select filesystem data within a chroot() - this is done with a "bind mount."
Why these two security features were not designed around all Android apps from the beginning is beyond me.
OpenBSD is one of the best on that front, but it is a defense-in-depth mechanism, not something designed to run known-malicious code.
There's another way: the app could instead use Android's Intent system to request a file chooser. This switches to a separate app which already has access to the filesystem (like the built-in Gallery app), which after the user has chosen the file, returns something which allows the original app access to just that file. This mechanism exists since the first version of Android.
At least you can turn it off later.
There's another point in favor of requiring it. The only downside I can see is that the people who most need to be scared by it would not be.
iOS has a framework to take actions directly from notifications without requesting permission.
Maybe it's smart enough to not DING! during a phone call. Now it needs permission to "make and manage phone calls".
Or that could be provided by the operating system without needing the feature....
Maybe there's a feature where it suggests a "here's my location" response when somebody texts you "where are you?". Now it needs permission to access your location.
Fair enough.
Contact integration? Camera integration? Access storage?
Why would it need to access storage outside of its own sandbox?
To allow you to send and receive attachments.
Name any one permission, I'm pretty sure I'll find a reasonable case for it to be used in a messenger app.
However, a pretty strong case can be made that current permissions allow for way too much. For instance, I should be able to send attachment by picking them through another (OS or third-party) file picker, so that the app only gets temporary, read-only access to the selected file. Similarly, for saving attachments the app needs only a virtualized location with write access.
Really, the problem is that all of that gets ridiculously complicated for an average smartphone users, which makes it trivial for app developers to "bribe" users by having the app essentially tell "give us permissions or else it won't work".
I'm all for aggressively delisting applications that refuse to work when non-essential permissions were not given. Something like PlayStore GDPR, only for permissions.
Then again I wouldn’t be surprised if google had botched this. They did it wrong for Google Drive apps, and as a result any app that wants to do something as outlandish as, say, opening a file requires read access to all files on your entire google drive, just to display a file picker.
Sometimes I wonder if anyone at Google actually thinks about these things, like, at all. How does this happen? What are those meetings like? Surely someone noticed? Ho do they think about “trust”? It never ceases to amaze me.
The native file picker on iOS works with iCloud and third party storage providers like Dropbox, OneDrive, Google Drive, and Box. Any storage provider can integrate with it including apps that store everything locally.
The most memorable example was trying to take a picture and the camera app telling me it needed permission to make phone calls. I still can't think of a single valid reason why a camera would need to make phone calls, so I refused, and blam, no pictures for me.
That being said, malware does make it into the iOS store, it just requires a fair bit more effort since an actual person is going to sit there and fiddle with the app before it can be listed.
> 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.
https://developer.apple.com/app-store/review/guidelines/#sof...
(Edit: obviously the ban is via reviewing apps in the store, not on the software level.)
it's also on the software level. If you are an app and want to mark parts of your memory as executable, you need a special entitlement that requires a signature from Apple. Only a very small amount of OS-bundled apps (Safari for example) and no third-party app have this entitlement.
This is a reason why for a long time web-views embedded into apps couldn't make use of JIT compiled JavaScript: Because the web view was loaded in-process with your app, there was no way to execute any of the compiled code.
Only with WKWebView this was fixed by running the webview in a secondary process that has the necessary entitlements and then rendering the view inside of your process. Getting there took Apple quite some time though.
Only static code loaded from disk is marked executable, but that's not writable in memory and it's only loaded into memory when it has a valid code signature signed by Apple.
So unless you manage to get Apple to sign your dynamically loaded payload, even if you sneak the functionality past app-review, there's no way to execute it.
You can't mark memory as executable and you can't have the OS load code not signed by Apple
In other words, even if you had some algorithm could somehow look at a program state and with 100% accuracy determine if that state was the start of an interpreter main loop, there would be at least one program where you couldn't be certain that you'd run your algorithm on every program state.
So the same techniques used by antiviruses, be it heuristics, signatures of known interpreters and droppers, simulated execution could be used by app stores to drastically reduce bad actors. The fundamental weakness will always be there for advanced, unique malware.
"Interestingly enough, we have also observed that most AV's also failed in detecting the dropper campaigns (sometimes for years), meaning that some awareness needs to be raised on the topic,"
Unfortunately, preventing loading executable code on Android would break many useful apps (e.g. Termux[1]). Also, arguably, it would mean that third-party browsers couldn't exist, since javascript is code, after all (iOS doesn't have this problem, as no third-party browser engines are permitted — all browsers are just skins over Safari).
OTOH, perhaps there could be a "permission-like"[2] flag on Android where an app would have to declare that it loads external executable code. Apps that did not use this flag, but were detected as updating executable code (even if not malicious), would be banned from Google Play. Diligent users could then check whether an app used this flag, if it seemed as if it shouldn't need it and be careful.
[0] https://developer.apple.com/app-store/review/guidelines/#sof... (§2.5.2)
[2] it wouldn't be an actual OS permission, just informational