J-x-Z/samsung-oneui-compiler-permission-check-removal

# Samsung One UI 编译器/优化器回归：专有系统服务中的权限检查被消除 ## 跨服务安全失效、Samsung 工单关闭以及随后恢复 KnoxGuard 检查 **最终审查草案 — 2026 年 7 月** 这是一份基于已发布软件、保留研究记录和供应商信件的独立技术研究出版物。Samsung 的工单关闭是作为一个按时间顺序发生的事实来呈现的，并不被表征为同意本报告或其发布。其目的是请求技术解释，鼓励进行完整的产品系列审计，并加强对 Samsung 用户的保护。 | | | |---|---| | 受影响范围 | 通过受影响的构建流水线构建的 One UI 产品中的 Samsung 专有组件 | | 观察到的设备类别 | 手机和手表 | | 已证实的服务 | KnoxGuard | | 其他候选领域 | 凭据管理、企业策略、VaultKeeper、RKP、电源管理 | | AOSP 状态 | 未被所检查的对比样本牵涉 | | 根源评估 | 高度确信存在共同的 Samsung 编译/优化缺陷；确切的编译器阶段未能独立识别 | | 供应商结果 | 侧重于编译器的报告 I-121208 在未提供针对具体方法的解释的情况下被关闭；随后在未通知的情况下，于报告指出的确切 KnoxGuard 组件中恢复了权限检查 | ## 执行摘要 本报告记录了 Samsung One UI 系统软件中一种系统性的权限检查移除模式。在互不相关的 Samsung 专有服务中，本应强制执行特权调用者权限的安全辅助程序调用被发布为无效的 `Object.getClass()` 残留： ``` securityHelper.getClass(); ``` 未使用的 `getClass()` 结果不会强制执行调用者权限。在最强有力的运行时案例中，同期记录显示，缺少特权 KnoxGuard 权限的调用者调用了 `isKGAllowDO()`，未出现预期的 `SecurityException` 并获得了正常结果。 这并不是一个孤立的、可疑的方法。相同的残留出现在负责凭据、企业管理、KnoxGuard、VaultKeeper、RKP 和其他 Samsung 框架功能的服务中。我在从手机和手表提取的 One UI 软件中观察到了这种更广泛的模式。受检的 AOSP 对比代码保留了其权限强制执行逻辑，并未表现出反复出现的 Samsung 辅助程序模式。 其分布、一致性以及后来的固件变化强烈表明这是一种特定于 Samsung 的编译器、优化器或密切相关的构建转换回归。如果没有 Samsung 的源代码和构建日志，就无法指出确切的内部编译器阶段，但“不相关的开发者各自独立地将安全检查替换为相同的无用 null 检查残留”这一说法并不能充分解释这些证据。 Samsung 关闭了报告 I-121208，声明其无法识别具体的漏洞。随后，记录显示在后来的固件中，在报告指出的 KnoxGuard 入口点以及整个 `KnoxGuardSeService` 中恢复了 `Utils.checkCallerAndKgPermission(mContext)`：0 个真实的辅助程序调用变成了 33 个，而可疑的残留降至 0。研究人员没有收到任何技术解释、修复通知或对此变更的确认。 后来的恢复与安全密切相关，并与报告指出的弱点直接吻合。已发布的二进制文件无法证明 Samsung 的内部意图，也无法确立本报告导致了该补丁。它们确实确立了一个客观的次序：报告了权限检查移除模式，工单被关闭，随后报告指出的确切强制执行机制又重新出现。 在 Samsung 确定受影响的构建阶段并发布完整的审计范围之前，合理的防御性假设是：**所有由同一流水线处理的 Samsung 专有 One UI 组件都需要审查**，而不是将调查局限于一部手机、一项服务或一个 API。 ### 报告 → 关闭 → 恢复 | 阶段 | 记录的证据 | 安全意义 | |---|---|---| | 报告 | `isKGAllowDO()` 在预期的特权权限执行点包含无效的辅助程序残留 | 发布的入口路径缺少其预期的调用者执行操作 | | 关闭 | Samsung：“我们无法识别具体的漏洞” | 没有在技术上解释任何指定的方法或反复出现的二进制转换 | | 恢复 | DZF2 记录在同一方法中包含 `Utils.checkCallerAndKgPermission(mContext)` | 明确的特权调用者执行机制重新出现 | | 类范围内的变更 | KnoxGuard 记录显示真实的辅助程序调用由 0 变为 33，可疑残留由多个变为 0 | 报告的组件获得了全面的安全相关强化 | ## 核心发现 1. 在互不相关的 Samsung 专有服务中存在反复出现的权限执行辅助程序残留。 2. 在至少一个记录在案的 KnoxGuard 案例中，出现了可观察到的服务执行，而没有预期的特权权限拒绝。 3. 在不止一个 One UI 设备类别中观察到了该模式。 4. 受检的 AOSP 对比没有显示出特定于 Samsung 的重复模式。 5. 后来的固件恢复了研究中指出的确切 KnoxGuard 权限执行辅助程序。 6. 保留的笔记显示了其他服务中的混合状态，这与不完整的或逐个组件的修复相一致。 7. Samsung 的最终回复没有包含对这种重复转换或其构建时来源的任何技术解释。 ## 为什么编译器/优化器解释是首要结论 `Object.getClass()` 作为 null 检查在优化后合法存留是可能的。随机的出现并不是漏洞。其安全意义来自于重复的上下文和跨构建的变更。 ### 1. 相同的残留跨越了互不相关的安全域 这种模式出现在凭据、企业、KnoxGuard、VaultKeeper 和 RKP 代码中的安全辅助对象旁边。与大量开发人员各自独立做出相同无意义替换相比，一种共同的构建机制能更好地解释这种分布。 ### 2. 残留出现在预期会有调用者执行的地方 这些不仅仅是任意的 `getClass()` 调用。其接收者反复是 Binder 接口方法处的安全或注入器辅助程序，而在这些方法中，特权调用者权限执行正是预期设计的一部分。 ### 3. 后来的构建在同一位置恢复了真实的辅助程序 记录的 DZF2 实现中，`isKGAllowDO()` 包含： ``` Utils.checkCallerAndKgPermission(mContext); ``` 较早的构建在该权限执行点记录了一个未使用的 `Object.getClass()` 残留。这种前后关系使得“无害的反编译器伪影”这一解释变得站不住脚得多。 ### 4. 该变更在 KnoxGuard 中是全面的，但在其他地方是混合的 保留的分析笔记记录了所有 33 个 KnoxGuard 辅助程序调用的恢复，并且没有留下任何可疑的类级别残留。据报道，凭据管理既包含已恢复的检查，也包含剩余的残留。这种形态与定向强化或分阶段修复相一致，但没有表现出全平台范围的审计。 ### 5. 受检的 AOSP 对比未重现该模式 证据指向 Samsung 专有源代码处理或 Samsung 的产品构建配置，而不是 Binder 本身或普遍的 AOSP 权限执行失败。 如果没有 Samsung 的构建流水线，确切的实现缺陷仍然无法得知。这种不确定性关乎的是**哪个内部构建阶段失败了**，而不是已发布的权限执行行为是否值得进行系统性调查。 ## 范围：One UI 平台，而非单一设备 最初的报告是在 Galaxy Z Fold 6 环境下提交的，但研究并未局限于该型号。在检查手表和其他手机版本的软件时，也观察到了类似的 Samsung 特有残留。 因此，范围应表述如下： 这并不意味着每一个带有 One UI 品牌的二进制文件都经过了单独测试。它的意思是这是一个**产品系列的安全回归，需要对通过受影响的 Samsung 流水线生产的每一个 One UI 二进制文件进行审计**。编译器或构建级别的缺陷不能负责任地被限制在最初发现它的设备上。Samsung 是唯一能够枚举哪些产品、分支和构建阶段共享了受影响转换的当事方。 ### AOSP 未受牵连 在检查的 AOSP 对比中未观察到 Samsung 反复出现的辅助程序模式，这些对比保留了其预期的执行逻辑。本研究中的任何证据都没有指出普遍的 AOSP 编译器或 Binder 缺陷。现有证据将该问题局部化到 Samsung 专有代码或 Samsung 对该代码的处理上。 ## 技术模型 与安全相关的出现具有以下结构： ``` external caller → Samsung Binder entry point → expected privileged access-control decision → ineffective helper residue instead of enforcement → privileged service logic → optional clearCallingIdentity() or lower trusted service ``` 并非每个 `getClass()` 都是易受攻击的。只有当满足以下条件时，候选对象才会成为访问控制缺陷： 1. 方法跨越了信任边界； 2. 预期会有特权调用者决策； 3. 发布的路径未执行该决策； 4. 调用者缺乏同等权限；以及 5. 访问到了受保护的数据或行为。 这种重复出现的模式之所以重要，是因为仅仅修复一个方法并不能证明由同一构建机制产生的其他实例也已被发现。 ## KnoxGuard 运行时案例 ### 预期的边界 ``` Service: knoxguard_service Interface: com.samsung.android.knoxguard.IKnoxGuardManager Method: isKGAllowDO() Permission: com.samsung.android.knoxguard.STATUS Protection level recorded during analysis: signature|privileged Expected helper: Utils.checkCallerAndKgPermission(mContext) ``` ### 记录的受影响结果 同期的研究记录包含： ``` [+] VULN CONFIRMED: isKGAllowDO = true ``` 该调用被记录为已完成，而没有出现预期的 `SecurityException`。一份恢复的历史源文件证实，最初的测试包包含了对 `isKGAllowDO()` 的直接 Binder 探测。 原始的 APK、完整的控制台日志、权限转储、SELinux 记录以及受影响的 DEX 工作区在计算机迁移期间丢失。因此，该结果是同期的运行时记录，而不是自包含的现代复现包。 历史事务映射很重要： - transaction 41：`isKGAllowDO()` - transaction 42：`isKGAllowADB()` 早先一份报告 transaction 42 返回 `1` 的 Samsung 评论，在此映射下涉及的是 `isKGAllowADB()`，因此不能用作 `isKGAllowDO()` 的证明。 ### 记录的 6 月恢复情况 保留的 DZF2 笔记报告： | `KnoxGuardSeService` | 较早的构建 | DZF2, SPL 2026-06-05 | |---|---:|---:| | `Utils.checkCallerAndKgPermission()` | 0 | 33 | | 可疑的 `Object.getClass()` 残留 | 多个 | 0 | 记录表明，被报告的确切方法从无效残留变成了真实的特权权限辅助程序。原始的 DZE1/DZF2 提取工作区已不再可用，因此这些计数是作为保留的分析记录呈现的，而不是重新生成的测量数据。 ## 更广泛的受影响面 | 领域 | 记录的观察结果 | 证据强度 | |---|---|---| | KnoxGuard | 在 `isKGAllowDO()` 处缺少预期的拒绝；后来的辅助程序恢复 | 最强有力的运行时记录加上保留的跨构建笔记 | | CredentialManagerService | 大量辅助程序残留；后来呈现已恢复/未恢复的混合状态 | 静态模式及支持性的 shell 路径结果 | | EnterpriseDeviceManager | 在与 管理 相关的入口点存在残留 | 静态候选；未确认破坏性影响 | | VaultKeeper / RKP | 类似的 Samsung 辅助程序残留 | 静态候选 | | PowerManager | 记录了息屏行为；后来注意到了显式的 `DEVICE_POWER` 执行 | 调用者先决条件未得到充分保留 | | 认证密钥路径 | 残留后紧跟 `clearCallingIdentity()` 和 `deleteKey()` | 静态候选；刻意未执行 | ### 静态身份洗白候选 最初的提交保留了这段已发布的字节码摘录： ``` 5b4646: invoke-virtual {v10}, Ljava/lang/Object;->getClass()Ljava/lang/Class; 5b464c: invoke-static {}, Landroid/os/Binder;->clearCallingIdentity()J 5b46de: invoke-static {v0}, LAttestationUtils;->deleteKey(Ljava/lang/String;)V ``` 破坏性的调用并未执行。它并非作为确认的密钥删除来呈现。它说明了为什么移除框架的访问控制决策可能比最初的 KnoxGuard 验证的返回值所暗示的更为严重。 ## 信任链影响 Samsung 框架服务是应用程序与企业、凭据、硬件支持或可信执行操作之间的特权中介。较低层通常信任源自 `system_server` 的请求，因为预期框架服务会验证原始调用者。 如果外部权限检查消失，然后该服务调用 `clearCallingIdentity()` 或使用自身身份进行委托，下层可能会收到一个形式上受信任的请求，而该请求实际上源自缺少所需权限的调用者。SELinux、内核或 TrustZone 可能完全按照设计运行，但仍然无法重建缺失的框架访问控制决策。 这是 Android 到 Samsung 信任链的削弱。这并不是声称 EL2、EL3 或 TrustZone 本身被直接攻破。 ## 漏洞利用链风险 缺少权限检查的原语很少需要自身成为一个完整的漏洞利用。此缺陷是一个**攻击链放大器**：它可以移除通常访问凭据、企业 管理、设备控制和硬件支持服务逻辑所需的特权进入条件。它可以作为更大链的一个阶段： - 访问受保护的设备安全状态； - 调用特权混淆代理服务； - 通过 `clearCallingIdentity()` 进行身份洗白； - 操纵企业或凭据状态； - 与单独的入口点、沙箱或逻辑漏洞进行交互。 在高价值服务中的复现增加了将一个或多个实例与其他严重漏洞组合利用的机会。本报告不声称在没有复现该组合的情况下存在具体的端到端多 CVE 链。未来与指定 CVE 或 SVE 的任何关联都应包含确切的调用者、数据流、受影响的构建以及最终的安全状态。 ## Samsung 的回应：工单关闭随后是未通知的执行机制恢复 所有门户时间均为 UTC。 | 时间 | 事件 | |---|---| | 6-05-22 15:55 | 提交报告 I-121208 | | 2026-05-22 23:02 | 提交额外受影响的服务和方法 | | 2026-05-26 06:12 | Samsung 表示已指派分析师 | | 2026-06-01 21:18 | 提交字节码摘录、探索性结果、锁定状态照片和 `code.zip` | | 2026-06-01 22:29 | 研究人员更正了未经验证的 TX6/TX11 锁定归因 | | 2026-06-02 05:52 | Samsung 关闭了报告 | Samsung 的回复如下： ### 程序对比：单独的报告 I-121195 I-121195 不是本报告的主题，也不作为对侧重于编译器的发现的第二次决定提出。将其包括在内仅作为分诊严谨程度的比较。 在 I-121195 结尾处，编译器模式作为一个简短的次要观察结果出现。Samsung 于 2026-05-22 对该单独提交回复称这是一个“没有实际安全影响的软件 bug”。该回复没有讨论编译器观察结果或反复出现的 `getClass()` 模式。 这种对比并不能确立 Samsung 在 I-121195 中充分评估了编译器问题。它显示了相反的局限性：在得出有关安全影响结论的同时，嵌入在报告中的不寻常的编译器相关线索没有得到明显的技术处理。上述专门的 I-121208 时间线仍然是用于评估 Samsung 如何处理本出版物主题的唯一供应商时间线。 最初的提交包含探索性材料和最初不正确且随后被迅速更正的锁定归因。然而，它确实向 Samsung 提供了指定的服务、具体的字节码位置、恢复的探测以及足以调查二进制文件生成缺陷的反复出现的安全辅助程序残留。Samsung 的最终回复没有提及任何一个指定的方法，没有解释这种重复的转换，也没有表明受影响的服务已作为一个整体进行了审计。 后来的 KnoxGuard 变更不能被合理地视为无关的噪音：在报告指出的边界处，确切预期会有的执行辅助程序重新出现，并且全类范围的记录计数从 0 变为 33。没有向研究人员发送任何修复通知或技术解释。 因此，可以准确地说，Samsung 关闭了提交的发现，随后**在确切被报告的组件中恢复了与安全相关的执行机制，而没有通知研究人员**。这描述了可观察的沟通记录，并不声称了解 Samsung 的私人意图。已发布的证据无法证明该报告是否导致了此变更，但它理应得到 Samsung 的直接解释。 ## CERT/CC VINCE 记录 该问题于 2026-06-02 提交给 CERT/CC。CERT/CC 索要了 Samsung 的论述，并要求提供更清晰的攻击者影响和可复现的 PoC。在讨论期间提供了关闭后的 KnoxGuard 运行时记录和 CredentialManagerService 观察结果。 CERT/CC 表示，除非证明预期的 KnoxGuard 功能被绕过，否则无法分配 CVE。在 2026-06-19，我撤回了报告以寻求独立出版。CERT/CC 既没有验证编译器根本原因，也没有确认该漏洞。 ## 本报告的主张与不包括的内容 ### 包含的主张 - 在互不相关的服务中，特定于 Samsung 的权限执行辅助程序残留反复出现； - 同期记录的 KnoxGuard 权限执行失败； - 在手机和手表中观察到的跨设备类别观察结果； - 后来记录的确切 KnoxGuard 辅助程序的恢复； - 高度确信存在共同的编译器/优化器/构建转换根源评估； - 对 Samsung 专有 One UI 组件进行全平台审计的要求；以及 - 重大的信任链和漏洞组合风险。 ### 不包括的主张 - 每个 `getClass()` 调用都是漏洞； - 每个 One UI 二进制文件都经过了单独测试； - 确认的密钥删除、凭据签名、管理员移除、密码重置或 root 访问权限； - TrustZone、EL2 或 EL3 的直接妥协； - Samsung 私人意图的证据；或 - 带有特定近期 CVE 的复现端到端链。 ## 证据局限性 - 原始的 DZE1/DZF2 DEX 对比工作区已丢失。 - 一些跨构建的计数仅存于 AI 辅助的同期分析日志中。 - 原始的普通应用程序包和完整的权限/SELinux 记录已丢失。 - 完整的手机/手表设备和构建清单未被保留。 - Binder transaction 编号是特定于固件的。 - 大多数候选服务未经过动态验证。 这些损失限制了独立复现历史构建的能力。它们并没有抹去保留的 Samsung 和 VINCE 记录、恢复的探测源代码、字节码摘录或记录的跨构建执行变更。 ## 建议 Samsung 应该： 1. 将通过受影响流水线构建的所有专有 One UI 组件视为在审计前均在范围内； 2. 识别并发布负责该转换的构建阶段； 3. 将必需的源码级执行调用与发布的 DEX 输出进行比较； 4. 以普通第三方应用程序身份测试每个特权 Binder 接口； 5. 逐个方法地审查所有安全辅助程序的 `getClass()` 残留； 6. 在 `clearCallingIdentity()` 之前验证原始调用者； 7. 在每个生产优化配置文件下测试权限执行包装器；以及 8. 发布受影响的产品、已修复的构建版本，以及是否已消除根本原因。 ## 仓库证据 - [`evidence/manifest.md`](evidence/manifest.md) 记录了已恢复历史工件的 SHA-256 哈希值。 - [`legacy-code/KgAllowDoHistoricalProbe.java`](legacy-code/KgAllowDoHistoricalProbe.java) 以精简、易于审查的形式保留了来自历史 KnoxGuard 探测的只读 `isKGAllowDO()` Binder 调用。 - [`legacy-code/README.md`](legacy-code/README.md) 记录了精简源代码的出处和局限性。 - 排除有状态更改、模糊测试、已编译、已签名和第三方工件。恢复的档案不完整且特定于固件，因此不应将其作为自包含的现代漏洞利用包呈现。 ## 结论 证据描述的不仅仅是一个缺失的检查。它描述了在 Samsung 专有服务中反复出现的**权限边界消除**，这在 One UI 设备类别中都有观察到，随后在最初的工单关闭后，恢复了确切的 KnoxGuard 执行机制。 最连贯的技术解释是一种特定于 Samsung 的编译器、优化器或构建转换的回归。只有 Samsung 能够识别确切的内部阶段和完整的受影响产品集。在此之前，将问题限制在一个 API 或一个型号上会低估安全风险。 原始提取工作区的丢失使得无法识别 Samsung 确切发生故障的编译器阶段。但这并不能解释掉记录在案的运行时权限执行失败、反复出现的 Samsung 特有残留，或是后来确切执行代码的重新出现。 公开记录理应得到 Samsung 的两个答复：为什么安全执行会以无效的辅助程序残留的形式发布，以及为什么在被报告的确切 KnoxGuard 检查恢复后，却没有相应的技术确认或根本原因解释。

标签：JS文件枚举, KnoxGuard, Samsung One UI, 域名枚举, 技术报告, 漏洞分析, 目录枚举, 移动安全, 编译器缺陷, 路径探测