简单讲讲五月份谷歌安全公告里几个框架层的漏洞
- https://source.android.com/security/bulletin/2021-05-01
CVE-2021-0485
- https://android.googlesource.com/platform/frameworks/base/+/aad7fdc4f82ad56e332d3c23c5d07719e069b099
这里的PiP就是Picture in Picture Mode,也就是画中画模式
在创建画中画任务时,强制要求画中画尺寸需要大于48dp*48dp
diff --git a/core/res/res/values/dimens.xml b/core/res/res/values/dimens.xml
+ <!--
+ The overridable minimal size of a PiP task, in both dimensions.
+ Different from default_minimal_size_pip_resizable_task, this is to limit the dimension
+ when the pinned stack size is overridden by app via minWidth/minHeight.
+ -->
+ <dimen name="overridable_minimal_size_pip_resizable_task">48dp</dimen>
diff --git a/packages/SystemUI/src/com/android/systemui/pip/PipTaskOrganizer.java b/packages/SystemUI/src/com/android/systemui/pip/PipTaskOrganizer.java
if (windowLayout.minWidth > 0 && windowLayout.minHeight > 0) {
- return new Size(windowLayout.minWidth, windowLayout.minHeight);
+ // If either dimension is smaller than the allowed minimum, adjust them
+ // according to mOverridableMinSize and log to SafeNet
+ if (windowLayout.minWidth < mOverridableMinSize
+ || windowLayout.minHeight < mOverridableMinSize) {
+ EventLog.writeEvent(0x534e4554, "174302616", -1, "");
+ }
+ return new Size(Math.max(windowLayout.minWidth, mOverridableMinSize),
+ Math.max(windowLayout.minHeight, mOverridableMinSize));
我之前见过一种保活机制,就是利用1像素来使进程一直在前台挂着,同时配合一个广播接收器,比如ACTION_SCREEN_ON
和ACTION_SCREEN_OFF
来持续启动组件,保活的骚操作还是挺多的
CVE-2021-0487
- https://android.googlesource.com/platform/packages/providers/CalendarProvider/+/8cddb2643dd823721ba5c897a089d06c56b50a60
补丁在启动com.android.providers.calendar.CalendarDebugActivity
的时候清空界面上所有第三方悬浮框,用于防止第三方应用弹出悬浮框遮盖按钮引导用户错误选择
diff --git a/AndroidManifest.xml b/AndroidManifest.xml
+ <uses-permission android:name="android.permission.HIDE_NON_SYSTEM_OVERLAY_WINDOWS" />
diff --git a/src/com/android/providers/calendar/CalendarDebugActivity.java b/src/com/android/providers/calendar/CalendarDebugActivity.java
+ @Override
+ protected void onStart() {
+ super.onStart();
+ getWindow().addSystemFlags(android.view.WindowManager.LayoutParams
+ .SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS);
+ }
+
启动Activity的手机界面如下
CVE-2021-0477
- https://android.googlesource.com/platform/frameworks/base/+/e01fef361bb7371e10b990737caed7a3799bdc3b
修改PendingIntent不可修改
diff --git a/packages/SystemUI/src/com/android/systemui/screenshot/ScreenshotNotificationsController.java b/packages/SystemUI/src/com/android/systemui/screenshot/ScreenshotNotificationsController.java
if (intent != null) {
final PendingIntent pendingIntent = PendingIntent.getActivityAsUser(
- mContext, 0, intent, 0, null, UserHandle.CURRENT);
+ mContext, 0, intent, PendingIntent.FLAG_IMMUTABLE, null, UserHandle.CURRENT);
b.setContentIntent(pendingIntent);
}
CVE-2021-0481
- https://android.googlesource.com/platform/packages/apps/Settings/+/d4f04398c71f67bc13f85e098e1dc71d840c1a4a%5E%21/#F0
添加校验传入的URI合法性
diff --git a/src/com/android/settings/users/EditUserPhotoController.java b/src/com/android/settings/users/EditUserPhotoController.java
final Uri pictureUri = data != null && data.getData() != null
? data.getData() : mTakePictureUri;
+
+ // Check if the result is a content uri
+ if (!ContentResolver.SCHEME_CONTENT.equals(pictureUri.getScheme())) {
+ Log.e(TAG, "Invalid pictureUri scheme: " + pictureUri.getScheme());
+ EventLog.writeEvent(0x534e4554, "172939189", -1, pictureUri.getPath());
+ return false;
+ }
+
CVE-2021-0480
- https://android.googlesource.com/platform/frameworks/base/+/c024c5886aaf4fc98c53a761398fac5c399de789
又是一个PendingIntent的问题,这里直接添加包名
diff --git a/services/core/java/com/android/server/notification/SnoozeHelper.java b/services/core/java/com/android/server/notification/SnoozeHelper.java
return PendingIntent.getBroadcast(mContext,
REQUEST_CODE_REPOST,
new Intent(REPOST_ACTION)
+ .setPackage(PackageManagerService.PLATFORM_PACKAGE_NAME)
.setData(new Uri.Builder().scheme(REPOST_SCHEME).appendPath(key).build())
.addFlags(Intent.FLAG_RECEIVER_FOREGROUND)
.putExtra(EXTRA_KEY, key)
我才疏学浅,讲的不对的地方大佬们包涵
关于PendingIntent大家可以仔细看看CVE-2020-0114
- https://android.googlesource.com/platform/frameworks/base/+/d16e86f466c2fc18448b654cbe71089c7fede991
KeyguardSliceProvider继承SliceProvider,在onCreateSliceProvider()
中会创建一个PendingIntent,没有指定包名,也没有指定Action,如果能拿到这个PendingIntent,那就可以使用特殊权限发送Intent
@Override
public boolean onCreateSliceProvider() {
synchronized (this) {
...
mPendingIntent = PendingIntent.getActivity(getContext(), 0, new Intent(), 0);
...
}
return true;
}
KeyguardSliceProvider导出,这就好办了
<provider
android:name=".keyguard.KeyguardSliceProvider"
android:authorities="com.android.systemui.keyguard"
android:grantUriPermissions="true"
android:exported="true">
</provider>
我们观察到KeyguardSliceProvider的父类SliceProvider实现了Call()
@Override
public Bundle call(String method, String arg, Bundle extras) {
if (method.equals(METHOD_SLICE)) {
Uri uri = getUriWithoutUserId(validateIncomingUriOrNull(
extras.getParcelable(EXTRA_BIND_URI)));
List<SliceSpec> supportedSpecs = extras.getParcelableArrayList(EXTRA_SUPPORTED_SPECS);
String callingPackage = getCallingPackage();
int callingUid = Binder.getCallingUid();
int callingPid = Binder.getCallingPid();
Slice s = handleBindSlice(uri, supportedSpecs, callingPackage, callingUid, callingPid); // <-- 1
Bundle b = new Bundle();
b.putParcelable(EXTRA_SLICE, s);
return b;
} else if (method.equals(METHOD_MAP_INTENT)) {
...
} else if(...) {
...
}
return super.call(method, arg, extras);
}
仔细往下分析的话就是这样,从handleBindSlice()
开始,会把上面初始化的PendingIntent打包到Slice里面返回
攻击者可以拿到这个PendingIntent,略加修改就可以做敏感操作,这个漏洞的利用细节上还需要用户交互一下
本来想先刷一下Android 12的预览版,发现支持的设备已经是Pixel 3起步了,手上这几个二手Pixel可真是太难了
目前来说某鱼上二手的Pixel大多都是工程机,工程机就是测试过程的机器,不是零售版,工程机比正式版的机器便宜得多,主要还是体现在硬件的差距上面,系统的话自己刷机问题都不大
现在二手Pixel 4的工程机大概是1.6k左右,零售版大概贵1k,工程机日常做测试还是很划算的
正式版的鸿蒙马上就发布,时间是六月二号晚上八点,可以蹲一下发布会,我挺期待的,现在国内的手机厂商能在国际舞台上打擂的只有华为,无论是从哪个角度来说我们都应该支持打造属于自己的手机系统生态
腾讯安全应急响应中心发布的《腾讯代码安全指南开源,涉及C/C++、Go等六门编程语言》
- https://security.tencent.com/index.php/blog/msg/189
网信办发布的《关于抖音等105款App违法违规收集使用个人信息情况的通报》,别光通报,罚钱!必须罚钱!
- https://mp.weixin.qq.com/s/jK6dsg45IwNiIHOIBQiVBg
CNCERT发布《2020年我国互联网网络安全态势综述》报告,国外APT组织对我国政府机构等部门的攻击形势依旧严峻,APP治理取得积极成效,公民个人信息泄露问题依旧存在,小程序作为迅速发展的技术同时也暴露出了很多安全问题,病毒对抗一直都有,攻击手段逐渐精细化,下一步的方向依旧是APP治理,供应链安全,公共基础设施安全,数字化转型过程中的数据安全能力
- https://mp.weixin.qq.com/s/a2nFajrBk3bxCynfC6hdQQ
我给大伙贴一下报告的下载链接
- https://www.cert.org.cn/publish/main/upload/File/2020%20CNCERT%20Cybersecurity%20Analysis.pdf
360手机卫士发布的《2021年第一季度中国手机安全状况报告》,主要还是手机诈骗,病毒之类的,我感觉这些年随着各大手机厂商自己搞系统之后,一般都会内置安全软件,导致360手机卫士这种第三方安全软件逐渐失去了市场,没了市场也就很难收集到足够多的数据做分析,其实这样的报告使用到的样本还是不够全的
- https://rs-beijing.oss.yunpan.360.cn/Object.getFile/360report/MjAyMeW5tOesrOS4gOWto+W6puS4reWbveaJi+acuuWuieWFqOeKtuWGteaKpeWRii5wZGY=
下面这个我没看懂,涉及JS的我一般都看的比较迟缓,有人给我讲讲吗?
《The Tangled WebView - JavascriptInterface once more》
- https://i.blackhat.com/asia-21/Friday-Handouts/as-21-Qin-The-Tangled-WebView-JavascriptInterface-Once-More.pdf
贴一下四大安全顶会,点赞关注不迷路:S&P,USENIX security,CCS和NDSS
2021 AsiaCCS议程,没找到Accepted Paper列表,各位凑合着看
- https://asiaccs2021.comp.polyu.edu.hk/program/
《Measuring User Perception for Detecting Unexpected Access to Sensitive Resource in Mobile Apps》
- https://publications.cispa.saarland/3291/1/asiafp017-nguyenA.pdf
《Malware Makeover: Breaking ML-based Static Analysis by Modifying Executable Bytes》
- https://users.ece.cmu.edu/~lbauer/papers/2021/asiaccs2021-advml-malware.pdf
对了,AsiaCCS在CCF的排名是C类,不过有的组织也把它算作B类
马上就是今年的S&P,前面说了这是个安全顶会,Accepted Paper列表如下,整体来说肯定是比B类,C类要有干货的多
- https://www.ieee-security.org/TC/SP2021/program-papers.html
挑一些我感兴趣的
《Android Custom Permissions Demystified: From Privilege Escalation to Design Shortcomings》
- https://diaowenrui.github.io/paper/oakland21-li.pdf
《ConDySTA: Context-Aware Dynamic Supplement to Static Taint Analysis》
- https://galadriel.cs.utsa.edu/~rslavin/publications/sp21.pdf
《Happer: Unpacking Android Apps via a Hardware-Assisted Approach》
- http://www4.comp.polyu.edu.hk/~leixue/papers/SP21-Happer.pdf
《How Did That Get In My Phone? Unwanted App Distribution on Android Devices》
- https://arxiv.org/pdf/2010.10088.pdf
《Trouble Over-The-Air: An Analysis of FOTA Apps in the Android Ecosystem》
- https://www.computer.org/csdl/pds/api/csdl/proceedings/download-article/1t0x9wqtFAI/pdf
《Trust, But Verify: A Longitudinal Analysis Of Android OEM Compliance and Customization》
- http://s3.eurecom.fr/docs/oakland21_pox.pdf