Android Broadcast component Permission Bypass Vulnerability

Android Broadcast component Permission Bypass Vulnerability

Lolipop source code has been released for some days. I found that google fixed a high-risk vulnerability on Android 5.0, which can be used to send arbitrary broadcasts: it can not only send broadcast at the protection level of the system, but also ignore the restrictions of the android: exported = false and android: permisson = XXX attributes of the attacker.

It is the broadcast version of The LaunchAnywhere vulnerability, so it is called broadAnywhere. This vulnerability can be killed in less than 5.0 of the system, which has a huge impact.

I. first look at the patch

Through the patch, we can see that the vulnerability occurs in the addAccount function of src/com/android/settings/accounts/AddAccountSettings. java. This vulnerability occurs when you add an account in Settings. The process for adding an account using AccountManager is as follows:

For more information about the process mechanism of AccountManagerService, see the LaunchAnywhere vulnerability analysis.

Ii. How to Use

This vulnerability occurs before step 1 of the flowchart. Setting calls AccountManager. addAccount. Added a PendingIntent when passing the AddAccountOptions parameter, whose intent type is Broadcast. Note that this PendingIntent is created by Settings and has the system permission.

AppB obtains the AddAccountOptions parameter in step 3, obtains the PendingIntent, and can use it to send broadcasts as a system. The sample code is as follows:

The System-level broadcast protected-broadcast can be sent as a System-level broadcast, and the broadcast can be sent to unexported referers (android: exported = false) and referers with limited permissions.

Iii. Principle Analysis

Let's look at how Settings creates PendingIntent:

Settings itself is a high-permission process. It is insecure to pass its PendingIntent to untrusted third-party programs.

Because Settings imports a new Intent () with no content when initializing PendingIntent, attackers can set most of the Intent content when calling PendingIntent. send. This is because PendingIntentRecord. sendInner in the system source code calls finalIntent. fillIn (intent, key. flags);, allowing the caller to fill in the Intent value.

PendingIntentRecord. java

Iv. hazards and application scenarios

This vulnerability can be detected in Android 5.0 or lower, and affects Android 99.9%.

This vulnerability can be exploited to attack the vast majority of broadcast referers. Because the Intent. fillIn function requires that the component must be explicitly filled, we cannot send the intent of the specified component. However, you can specify the intent action to attack most of the reducers.

Therefore, this vulnerability is quite usable. The following are examples:

1. Send android. intent. action. BOOT_COMPLETED broadcast, which is a broadcast action protected by the system. Sending this broadcast will cause system_server to crash and cause local DoS attacks. 2. android. provider. Telephony. SMS_DELIVER sent on 4.4 can be forged to receive text messages. 3. Send com. google. android. c2dm. intent. RECEIVE broadcast, and the device will be restored to the factory settings.

The above exploitation methods are already open-source:

Https://github.com/retme7/broadAnyWhere_poc_by_retme_bug_17356824

For firmware customization by the manufacturer, more methods may be available. By searching the attacker of the system application, you can find more attackers. For the search method, refer to the following code (python ):

V. Vulnerability repair

Note that this PendingIntent is used to notify a third-party application, and the application initiating addAccount is Settings. In fact, it is not necessary to use PendingIntent here, but for historical reasons, this interface still has to be supported.

Therefore, the vulnerability is fixed by initializing a meaningless value in the component, action, and action associated with the PendingIntent. In this way, AppB cannot use Intent. fillin () to refill the intent value.

6. Recommended Security developers:

Try not to use the volume er as the interface for calling sensitive functions, even if the volume er is not exported and has permission control.