Android Broadcast Assembly permission bypass vulnerability-vulnerability warning-the black bar safety net

2015-08-02T00:00:00
ID MYHACK58:62201565276
Type myhack58
Reporter 佚名
Modified 2015-08-02T00:00:00

Description

Lolipop source code has been released some days, I found google in Android 5.0 on the Fix a high risk vulnerability, exploit the vulnerability you can send any broadcast: not only can you send a system protection level of the broadcast, you can also ignore receiver android:exported=false android:permisson=XXX properties of the limit.

It's LaunchAnywhere[1] exploits the broadcast version, so we called it broadAnywhere. This vulnerability in the 5. 0 the following system on the pass to kill, the impact is still very large.

A look at the patch !

By patch[2]可以 看 到 漏洞 发生 在 src/com/android/settings/accounts/AddAccountSettings.java the addAccount function. This time the vulnerabilities occur in the Settings Add account. Use the AccountManager to add an account the process is as follows figure:

! on the AccountManagerService flow mechanism please refer to the LaunchAnywhere vulnerability analysis[1], The present article will not repeat them here.

Second, how to use

This vulnerability occurs in the flow chart Step1 before, Setting calling the AccountManager. addAccount is. In the transfer of AddAccountOptions parameters when added to a PendingIntent, intent type is Broadcast on. Note that this PendingIntent is Settings created with system permissions.

!

AppB will in step3, the time taken to AddAccountOptions parameters, obtained from this PendingIntent, and you can use it to system The identity of the transmitted broadcast, the sample code is as follows:

!

To System status can be sent a system-level broadcast protected-broadcast, but also can be broadcast to not export receiver android:exported=false and reserves the right to limit the receiver.

Third, the principle of analysis

Look back and then look at the Settings is how to create the PendingIntent:

!

The Settings itself is a high privilege process, it will own the PendingIntent passed to the untrusted third-party app is unsafe.

Because Settings initializing the PendingIntent when an incoming is a no-content new Intent (), so the attacker is in the call to PendingIntent. send( )when you can freely set the Intent of most of the content. This is due to the system source code PendingIntentRecord. sendInner call finalIntent. fillIn(intent, key. flags);, and allows the caller to fill the Intent of the value.

PendingIntentRecord.java

!

Fourth, vulnerability to harm and scenarios

This vulnerability in Android 5. 0 following pass to kill, can be considered the vulnerability affects currently 9 9. 9%of Android phones.

The use of this vulnerability can attack the vast majority of the broadcast receiver. Due to the Intent. fillIn this function requires the component must be explicitly filled[3], We can not send the specified component of the intent. But you can by specifying the intent action can already attack most of the receiver.

So this vulnerability is also a great use of space. Here are a few examples

  1. Send android. intent. action. BOOT_COMPLETED broadcast, which is a system of protection of broadcasting the action. Send this broadcast will cause the system_server direct collapse, resulting in a local DoS attack.
  2. 4.4 on sending android. provider. Telephony. SMS_DELIVER can fake received SMS.
  3. Send com. google. android. c2dm. intent. RECEIVE a broadcast, the device will restore to factory settings.

The above-mentioned several kinds of use of the method has been open source:

https://github.com/retme7/broadAnyWhere_poc_by_retme_bug_17356824

Fake SMS demo video:

For manufacturers of custom firmware, it may have more use of the method. Through the search system application of the receiver, you can find more may attack the receiver, the search method can refer to the following code in python: the

!

Five, bug fixes

By comments know this PendingIntent is used to tell third-party applications, launched addAccount application is Settings. Here actually it is not necessary to use a PendingIntent, but for historical reasons, this interface also have to continue to support indefinitely.

So this vulnerability fix is simply the PendingIntent associated with the Intent of the component, action, action initialize a meaningless value. As a result AppB also will not be able to by means of Intent. fillin()on the intent value of the secondary fill.

!

Six Safety recommendations

Developer:

Try not to use the receiver as a sensitive function of the call interface, even if this receiver is not exported, the right to limited control.

Mobile phone manufacturers:

As soon as the firmware upgraded to Android Lolipop is. Or with reference to the link[2]to push the Security Update Patch.

[1] http://retme.net/index.php/2014/08/20/launchAnyWhere.html

[2] https://android.googlesource.com/platform/packages/apps/Settings/+/37b58a4%5E%2 1/#F0

[1] [2] next