Security threat by a BroadcastReceiver with GooglePlay's permissions - android

Does the following situation create a security threat?
Image a situation.
You have a device without GooglePlay services installed.
You create a broadcast receiver with android:permission="com.google.android.c2dm.permission.SEND" permission (this permission is held by GooglePlay services) and install this app on the device.
The app does not check if GooglePlay services are available on the device.
Is it possible for a malicious software to exploit this developer mistake?

It's not very likely that this would cause a problem. There's minimal issue with this because:
This permission is defined by Google for GCM (which has been replaced by FCM.) It is used to ensure that only senders who hold this permission can send that Intent to the registered receivers. It's a small amount of security in the grand scheme of things, though.
Even if a different app / service defined this same permission to fake it on a device where GMS is not present, the normal payload of the Intent is likely going to have some type of extra data in it so Google's receiver (what is specified in your manifest) can verify its content before doing anything with it.
Starting with Android 4.4.3, checks were added to the system so that system bundled apps/services (e.g. GMS) permission definitions take precedence over 3rd party apps. This prevents 3rd party apps from re-defining permissions in an attempt to back-door a system app permission. Not exactly the same situation you describe, but still important.

Related

Receive Broadcasts from System Only

I'm writing an Android app that deals with several external USB devices. Stakeholders have expressed security concerns around BroadcastReceivers because of SonarQube feedback, and it seems legitimate enough to pursue.
Is there a way to determine that a Broadcast (e.g. ACTION_USB_DEVICE_ATTACHED) came from the system itself, and not a third-party?
BroadcastReceivers can be restricted to receive Intents only from sources that have specific permissions granted. Is there a permission that only the system has that could be used to the desired effect?

Permission handling for privileged system apps

I'm writing an Android app, that will run on custom hardware with a ROM that I have control of.
The device will run a single application (as a launcher) and once the device is deployed I (generally) do not have access to it anymore. The app also has support for updating itself.
As such, I need a way to properly handle permissions for the app i.e. permissions need to be granted automatically (including dangerous ones) if they are ever added to the manifest.
Now, the app is being signed by the same certificate as the Android OS running on the device, and the app is placed in the priv-app directory when the device is flashed.
I assumed that this would automatically grant permissions but this does not appear to be the case.
I have tried adding android:sharedUserId="android.uid.system" to the manifest, and that does indeed grant all permissions, but since there are already quite a few legacy devices "in the wild", adding this option makes it so that the app can no longer be updated (throwing a INSTALL_FAILED_SHARED_USER_INCOMPATIBLE error).
So, what is the best way to handle permissions in this case? Is there some other voodoo magic I am missing here? Should I just bite the bullet, add the sharedUserId option and manually update all devices (undesired, but possible option)?

Android App build with Adobe Flash Builder requires STICKY BROADCAST permission. Why?

Yesterday I wanted to deploy/publish my first Android app at google play store but get stuck on the STICKY_BROADCAST permission that is needed/added.
Explanation on the google play store permission tab of the app:
SEND STICKY BROADCAST
Allows the app to send sticky broadcasts, which remain after the broadcast ends. Malicious apps may make the tablet slow or unstable by causing it to use too much memory. Allows the app to send sticky broadcasts, which remain after the broadcast ends. Malicious apps may make the phone slow or unstable by causing it to use too much memory.
I don't want that users may think that my app is an evil or slow app (BECAUSE I DON'T USE ANY STICKY_BROADCAST functionality in my CODE). How can i remove this permission or is it required by Adobe Air? Just one article found on the adobe site (with sort of same question) but without an answer.
In the app.xml configuration I defined only two permissions:
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.VIBRATE"/>
I use the internet connection to get some configuration for the app. I use the vibrate ane of adobe examples to vibrate the phone when the user tap the screen.
Why is the permission SEND STICKY BROADCAST needed/added to the package when I deploy/publish the app and what can I do to avoid it. Or better: Is there a way to avoid this permission?
I have the same problem and I just discovered it was caused by the adobe air I packaged together with my apk file.
Either you tell the user to download adobe air or get a newer version of flex.
Sorry I am late, I started working with flash just last week.

how are android security permissions checked at run-time?

This question has been asked before at How does Android enforce permissions?. While the discussions there are good, the question is still not fully answered.
In the development environment, exceptions are thrown when the app tries to do something that requires permissions not declared in AndroidManifest.xml. So how does the run-time system implement the run-time checking?
I guess it's most likely done in the core framework, which may or may not need support from native code. But I don't know what source code files in AOSP are relevant to this.
Android uses a lot of the standard Linux(-kernel?) mechanisms especially when it comes to hardware restrictions.
Every app gets assigned a new unique (Linux-)user id and whenever the app process is created the system creates it with that user id. The id will never change unless you remove the app. That means for accessing the lower system levels your app will appear as a certain user and every (Linux-)permission system that works with users will also apply to your app.
If you request WRITE_EXTERNAL_STORAGE in the manifest your app will also become member of the (Linux-)group (called sdcard_rw) that has permissions to write to that storage. Permissions on the filesystem are enforced to only allow writing to the system user (=owner) and the sdcard_rw group, anyone else (=other) may only read. See also Is Google blocking apps writing to SD cards
By doing that Android has to do pretty much nothing except for setting the correct UID/GIDs of the processes it spawns once the app starts and the rest is handled at lower levels. Apps that are not member of a certain group simply don't get access to certain hardware.
List of permission <> group mappings: platform.xml
There are also some (Android software) restrictions that are based on either the signature of your app and / or simply by looking up the permissions your app requested: e.g. ContextImpl#checkPermission() - but those permissions have to be checked at every entrypoint to code that allows restricted actions.
From time to time people discover ways to e.g. turn on GPS programmatically because a check like that is missing somewhere.
With regard to your second paragraph, "exceptions" are runtime faults. Permissions are not enforced at build time, only at run time.
Accessing hardware, low level operating system resources, and system files generally requires the app userid to be a member of an appropriate group which it may be assigned by the package manager as a result of having a corresponding android permission. (Familiar examples of that would be network sockets, and the sdcard write which zapl mentioned, but also system-only things like talking directly to the GSM modem or reading the raw touchscreen coordinates).
For the majority of android operations that are done by way of calling library functions which are stubs for interprocess communication to services running in a different process, the platform code running in the more privileged process on the receiving end of the ipc request checks with the package manager to find out if the calling application has the necessary android permission.
Many special permissions are only available to apps signed with the system signature - even if another app claims those in its manifest, they will not be applied by the package manager.

Scan the Application during the installation process in android

i just want an application that would scan the installing application and decide whether to deny the installation process or not basing upon the package name ?
Fortunately, this is not possible, for obvious security reasons. Malware authors would really like it if they could block other applications from being installed.
Do you want an application which self-checks for integrity?
Or an application which check ANY other new application?
On the former, I would suggest to put some piece of code on the main activity which checks this. But if you are trying to have some sort of 'anti-hacking' feature it would be quite pointless, as it would simply be needed to remove those lines.
On the latter, that would be more complicated and, also, how would you know the 'correct' package name?
Third party security applications such as Lookout, McAfee, Avast, etc. run with the same limited permissions and capabilities as any other Android application. That said, it's not possible for any Android application to "man-in-the-middle" an application installation process for security checks or any other purpose. As mentioned by others, this would have negative security implications, as it would allow any application to modify or deny the installation of other apps.
As a third party app, the best you can do is to monitor installed packages using a broadcast receiver that listens for android.intent.action.PACKAGE_ADDED intents, or use FileObserver to trigger a security review once the app is written to the file system. At this point if you detected an application you wanted to uninstall, you would still have to ask the user for their approval to uninstall the application.
FWIW, device manufacturers have the capability to make low-level modification to provide this capability, but I assume this is out of scope for your case.

Categories

Resources