Page History

...

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 bu by using Intent.setPackage().

Yet another approach is to use the LocalBroadcastManager class. Using this class, the intent broadcast it never going goes outside of the current process. According to the Android API Reference, LocalBroadcastManager has a number of advantages over Context.sendBroadcast(Intent):

• You know that the data you are broadcasting won't leave your app, so don't need to worry about leaking private data.
• It is not possible for other applications to send these broadcasts to your app, so you don't need to worry about having security holes they can exploit.
• It is more efficient than sending a global broadcast through the system.

Noncompliant Code Example

This noncompliant code example shows an application (com/sand/airdroidsample/ServerService.java) with a vulnerable method d() using an implicit intent v1 as an argument to this.sendBroadcast() to broadcast the intent. The intent includes such sensitive information as the device's IP address (local_ip), the port number (port), and the password to connect to the device (code).

public class ServerService extends Service {
  // ...
  private void d() {
    // ...
    Intent v1 = new Intent();
    v1.setAction("com.sample.action.server_running");
    v1.putExtra("local_ip", v0.h);
    v1.putExtra("port", v0.i);
    v1.putExtra("code", v0.g);
    v1.putExtra("connected", v0.s);
    v1.putExtra("pwd_predefined", v0.r);
    if (!TextUtils.isEmpty(v0.t)) {
      v1.putExtra("connected_usr", v0.t);
    }
  }
  this.sendBroadcast(v1);
}

...

final class MyReceiver extends BroadcastReceiver {
  public final void onReceive(Context context, Intent intent) {
    if (intent != null && intent.getAction() != null) {
      String s = intent.getAction();
      if (s.equals("com.sample.action.server_running") {
        String ip = intent.getStringExtra("local_ip");
        String pwd = intent.getStringExtra("code");
        String port = intent.getIntExtra("port", 8888);
        boolean status = intent.getBooleanExtra("connected", false);
      }
    }
  }
}

Proof of Concept

An attacker can implement a broadcast receiver to receive the implicit intent sent by the vulnerable application:

public class BcReceiv extends BroadcastReceiver {
  @Override
  public void onReceive(Context context, Intent intent){
    
    String s = null;
    if (intent.getAction().equals("com.sample.action.server_running")){
      String pwd = intent.getStringExtra("connected");
      s = "Airdroid  => [" + pwd + "]/" + intent.getExtras();
    }
    Toast.makeText(context, String.format("$B!V(B%s$B!W(BReceived%s Received", s),
                   Toast.LENGTH_SHORT).show();
  }
}

...

Using an implicit intent can leak sensitive information to malicious apps or result in denial of service.

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.

...

• JVN#67435981 LINE for Android vulnerable in handling of implicit intents
• JVN#42625179 Loctouch for Android vulnerable in handling of implicit intents

Related Guidelines

Bibliography

...

Image Added Image Added Image Added