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 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.
By patch可以 看 到 漏洞 发生 在 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:
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.
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.
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, 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
The above-mentioned several kinds of use of the method has been open source:
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
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.
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.
As soon as the firmware upgraded to Android Lolipop is. Or with reference to the linkto push the Security Update Patch.
 https://android.googlesource.com/platform/packages/apps/Settings/+/37b58a4%5E%2 1/#F0