【原创缝隙】AOSP跨用户资源接见缝隙
颁布功夫 2025-05-09Android的多用户机造是指系统支持在统一台设备上创建多个用户账户，每个账户占有独立的利用环境、数据和设置，重要用于平板设备、共享设备、企业治理设备等场景 。GA黄金甲ADLab通过对多用户模式下隔离机造发展安全钻研，聚焦系统跨用户资源接见的输入蹊径传染问题，挖掘了多个AOSP高危缝隙 。此表，还发现国内表主流厂商中也存在同类型高危缝隙CVE-2024-34674、CVE-2024-34672、CVE-2025-20883、CVE-2024-49402等 。
2.1 根基类型
Android系统界说了多种用户类型：
? Primary User（主用户）：设备初始化时创建的第一个用户，占有所有系统权限，唯一能够接管OTA 。
? Secondary User（次用户）：类似独立账号，无法接管OTA，不具备设备治理权限 。
? Guest User（访客用户）：一时用户，退出后会删除所罕见据 。
? Profile（配置文件）：Work Profile工作配置文件用于BYOD企业场景，与主用户隔离但共享部门资源；Restricted Profile限度配置文件用于平板多用户模式，限度权限和接见内容 。
对应权限隔离安全机造：
? 各用户权限独立授予 。
? 一个用户授予权限不会影响其他用户 。
? 跨用户通讯必要系统权限，如：INTERACT_ACROSS_USERS或INTERACT_ACROSS_USERS_FULL 。
? 通常三方利用无法通过Intent、ContentProvider 等越权接见其他用户的数据或服务 。
2.2 �；せ�
Android系统执行了多种�；せ煲栽し揽缬没У姆阜ㄗ试唇蛹� 。在Android中，URI的接见权限是由ContentProvider统一治理和节造的 。当用户A的利用携带特定URI提议某个作为要求时，系统组件会通过挪用链进入queryContentProviders步骤来验证该URI的接见权限 。
具体代码实现如下：
这个函数首先查抄利用是否携带了"@userid!=currentuserid"的象征，以此判断是否存在跨用户URI接见的情况 。若是的确涉及跨用户接见，则挪用checkCrossUserPermission来检验是否有跨用户接见的权限，并同时确认接见是否起源于system/root用户ID 。若是不是system/root用户，函数将持续查抄该利用是否占有INTERACT_ACROSS_USERS_FULL或INTERACT_ACROSS_USERS系统权限 。若上述前提均未满足，则不允许进行跨用户URI资源的接见 。
若是同时满足以下三个前提，系统可能存在跨用户的资源接见缝隙：
? 系统利用中存在设置为exported=true的组件；
? 该组件能够接管三方利用传入的URI参数，并且未对userid与当前currentUserId进行安全校验；
? 系统利用的AndroidManifest.xml中声了然INTERACT_ACROSS_USERS或INTERACT_ACROSS_USERS_FULL权限 。
三、缝隙道理分析（Android-337184703）
缝隙存在于deskclock apk�？橹�，此�？槲狝OSP通用铃声系统利用，供给用进行拓展铃声自界说设置 。
deskclock�？榫弑窱NTERACT_ACROSS_USERS*权限 。在HandleSetAlarmApiCalls的挪用链中，系统将导出组件盛开给三方利用，存在安全隐患 。具体挪用流程如下：
HandleSetAlarmApiCalls/HandleSetAlarm.onCreate
└──> handleSetAlarm(intent)
└──> updateAlarmFromIntent(intent, alarm)
└──>alarm.alert=getAlertFromIntent(intent, alarm.alert)
由于getAlertFromIntent未对传入的URI参数进行任何校验，便直接设置alarm.alert，可能导致三方利用传入恶意URI，从而引发权限绕过或信息泄露等风险 。
攻击者能够机关恶意挪用链，通过传入特定的URI参数并指定指标用户的userId，进而触发系统组件的处置逻辑 。在未进行用户身份校验的情况下，系统会直接使用该URI设置alarm.alert字段 。由于该URI可指向其他用户空间下的资源，攻击者可进一步通过遍历_id字段，达到肆意读取并窃取其他用户音频文件的主张 。
Google Android安全团队对GA黄金甲ADLab提交的缝隙汇报进行了评估，确定该缝隙为高危级别 。鉴于建复存在的难题，在最新颁布的版本中，已弃用了存在缝隙的组件，并在新版本当选取其他组件进行代替 。
为了预防此类问题，建议设置权限最幼化，审慎使用INTERACT_ACROSS_USERS*这类权限，此表，对盛开组件进行userid是否为currentuserid的安全校验 。
? 2024年4月26日 ADLab向Goolge提交Android系统安全汇报 。
? 2024年4月30日 ADLab补充细节 。
? 2024年5月8日 Goolge确认缝隙评级以及高危嘉奖 。
? 2024年12月11日 双方沟通建复规划 。
? 2024年12月24日 Google最终终场该职能开发，使用其他组件代替该职能 。
GA黄金甲积极防御尝试室（ADLab）
ADLab成立于1999年，是中国安全行业最早成立的攻防技术钻研尝试室之一，微软MAPP打算主题成员，“黑雀攻击”概想首推者 。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计颁布安全缝隙6500余个，持续维持国际网络安全领域一流水准 。尝试室钻研方向涵盖基础安全钻延注数据安全钻延注5G安全钻延注AI+安全钻延注卫星安全钻延注运营商基础设施安全钻延注移动安全钻延注物联网安全钻延注车联网安全钻延注工控安全钻延注信创安全钻延注云安全钻延注无线安全钻延注高级威胁钻延注攻防匹敌技术钻研 。钻研成就利用于产品主题技术钻延注国度沉点科技项目攻关、专业安全服务等 。
京公网安备11010802024551号