...
To broadcast an intent it is passed to Context.sendBroadcast() to be transmitted and interested receivers can receive the intent, dynamically registering themselves by calling Context.registerReceiver() with the specified intentFilter as an argument. Alternatively, receivers can be statically registered by defining the <receiver> tag in the AndroidManifest.xml file.
Chin, et al., [Chin 2011] say: "Broadcasts can be vulnerable to passive eavesdropping or active denial of service attacks. ... Eavesdropping is a risk whenever an application sends a public broadcast. (A public broadcast is an implicit Intent that is not protected by a Signature or SignatureOrSystem permission.) A malicious Broadcast Receiver could eavesdrop on all public broadcasts from all applications by creating an Intent lter that lists all possible actions, data, and categories. There is no indication to the sender or user that the broadcast has been read. Sticky broadcasts are particularly at risk for eavesdropping because they persist and are re-broadcast to new Receivers; consequently, there is a large temporal window for a sticky broadcast Intent to be read. Additionally, sticky broadcasts cannot be protected by permissions."
Furthermore, if the broadcast is an ordered broadcast then a malicious app could register itself with a high priority so as to receive the broadcast first. Then, it could either cancel the broadcast preventing it from being propagated further, thereby causing a denial of service, or it could inject a malicious data result into the broadcast that is ultimately returned to the sender.
Chin, et al., [Chin 2011] also warn against activity and service hijacking resulting from implicit intents. A malicious activity or service can intercept an implicit intent and be started in place of the intended activity or service. This could result in the interception of data or in a denial of service.
When sendBroadcast() is used, normally any other application, including a malicious application, can receive the broadcast.
This facilitates intent sniffing, see [viaForensics 2014] 26. Android: avoid intent sniffing.
Therefore, receivers of broadcast intents should be restricted. One way to restrict receivers is to use an explicit intent. An explicit intent can specify a component (using setComponent(ComponentName)) or a class (using setClass(Context, Class)) so that only the specified component or class can resolve the intent.
It is also possible to restrict the receivers of intents by using permissions, as described below. Alternatively, starting with the Android version ICE_CREAM_SANDWICH (Android API version 4.0), you can also safely restrict the broadcast to a single application by using Intent.setPackage().
Yet another approach is to use the LocalBroadcastManager class. Using this class, the intent broadcast never goes outside of the current process. According to the Android API Reference, LocalBroadcastManager has a number of advantages over Context.sendBroadcast(Intent):
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
DRD03-J | HighMedium | Probable | Medium | P12P8 | L1L2 |
Automated Detection
Automatic detection of the use of Context.sendBroadcast() is trivial. It is not feasible to automatically determine whether LocalBroadcastManager.sendBroadcast() can be used instead.
...
4.2.2.5. When sending sensitive information with a broadcast, limit the receivable receiver |
Bibliography
| [Chin 2011] | Analyzing Inter-Application Communication in Android |
4.2.2.5. When sending sensitive information with a broadcast, limit the receivable receiver | |
| [viaForensics 2014] | 26. Android: avoid intent sniffing |
...