概述
该问题于2019年12月31日根据Huawei移动端的漏洞条款公开，漏洞情况结果已于2021年9月1日报告给华为。考虑到修复已经过去了很久，并且我们认为该问题不可远程利用。
在撰写这篇文章时（2023年），该问题仍然可以在最新的EMUI（12.0.0.149）上通过强制加载漏洞进行本地利用。所以我们不公开易受攻击的版本以及恶意主题的POC，而且本地利用暂时无影响，所以整理此经历，并希望促进安全研究人员在研究华为基于EMUI的设备中的问题方面的工作。
背景
主题管理器允许EMUI设备上的自定义主题来风格化偏好，以及锁屏，壁纸和图标的自定义。能够进行这些类型的系统范围更改的进程需要具有更高的权限，使其成为研究和利用的有价值的目标。
在EMUI上实现锁屏时，使用了三种可能的引擎：
-
com.ibimuyu.lockscreen
-
com.vlife.huawei.emuilock
-
com.huawei.ucdlockscreen
安装主题SystemUI.apk时，将根据硬编码的受信任列表验证尝试进行这些更改的应用程序的签名。从我们分析到的情况来看，整个流程很完善，没有找到方法来绕过签名检查。
也就是说，我们发现当使用com.huawei.ucdlockscreen时，它会在运行时加载额外的类。这些类的签名没有被正确地验证，甚至也没有被检查。这为我们绕过并执行自己的代码提供了一个机会。
看看主题归档文件的结构（.hwt），我们看到解锁屏幕元素打包如下：
在unlock目录中查看，我们看到了theme.xml该文件，它指定了几个属性的清单。这些设置包括要使用的动态解锁引擎（在我们的例子中ucdscreenlock）和一个ucdscreenlock文件，该文件允许从主题文件中动态加载Java代码。
让我们看看文件内容：
利用logcat程序，我们可以看到动态加载过程：
此漏洞已通过在EMUI 9.1和10上的可以直接复现利用，但似乎对当前版本的EMUI存在一些限制 *。
像前面的分析所说，这会导致使用高特权应用程序的PID执行任意代码。在我们的测试中，利用漏洞获得了大约200个Android和Huawei自定义权限。其中包括下面列出的权限，这些权限可能会导致设备的用户数据、敏感系统数据、输入系统的任何凭据以及系统环境的完整性完全受损。
考虑到应用程序可以发送huawei.android.permission.HW_SIGNATURE_OR_SYSTEM权限意图，我们认为可以利用现有的系统功能来获得系统级代码执行。一旦实现，可能获得系统的完全控制权。
漏洞利用方式
这个问题可以稳定地利用，没有任何技术障碍。也就是说，攻击需要目标安装自定义恶意主题。要远程完成此操作，需要用户交互。需要社会工程配合进行，，或者可以使用第二个强制下载和安装主题。利用主题赠送给其他用户的功能，因此可以利用（或欺骗）受损的受信任联系人来说服受害者接受并安装恶意主题。例如，以下URL将打开主题礼品页面： hwt://www.huawei.com/themes?type=33&id=0&from=AAAA&channelId=BBB
其次，攻击者可以在线发布指向恶意主题的链接或二维码，然后说服受害者使用该方案通过深层链接触发应用程序。
当然，现在华为对新主题和壁纸有一个审查流程，这可能会限制利用此漏洞的实时主题的使用和一些绕过技巧。
修复情况：
华为于2022年2月24日发布了HwThemeManager的更新（内部跟踪为HWPSIRT-2019-12158），称此问题已得到解决。尽管如此，我们相信这个问题实际上已经在（版本3和更高版本）中解决了。
这是一个重要的区别，因为最新版本的是由HwThemeManager在应用需要此类引擎的主题后在运行时安装的。即使在普通手机上（EMUI 9，10和最新的12.0.0.149），具有物理访问权限的攻击者也可以卸载最新版本并安装旧的易受攻击版本，因为它是由华为正确签名的。
如果没有华为的进一步缓解措施，对设备具有物理访问权限的攻击者仍然可以利用此漏洞获得系统特权访问，即使是最新的设备。
进一步探索：
经过几个小时的逆向工程的最新版本com.huawei.ucdlockscreen（版本4.6）中引入的修复，我们发现了一个额外的旁路影响EMUI9.1版本。此问题不需要物理访问，并且可以再次触发相同的可利用条件。
在加载主题期间，最新版本com.huawei.ucdlockscreen的将检查/data/themes/0/unlock/ucdscreenlock/error文件是否存在。因为/data/themes/0/所有的文件都是从提供的主题文件（.hwt）中复制的，所以它们都可以被攻击者控制。
此文件用于检查主题的特定版本。攻击者可以简单地嵌入引用旧版本的错误文件，从而强制支持遗留主题。这样做时，攻击者还会在ext.properties文件中指定一个虚构的包名。恶意.hwt文件中的这种更改组合绕过了所有必需的检查，使该问题在最新的EMUI9.1上再次可利用，不需要物理访问。在我们进行调查时，其他EMUI主要版本似乎实现了签名验证机制来缓解这种情况。
总结：
虽然依靠签名验证来验证软件组件可能是一种有效的安全措施，但必须彻底扩展它以包括任何动态加载的代码。也就是说，华为似乎不再提供bootloader解锁选项（请参阅此处https://consumer.huawei.com/en/community/details/Huawei-s-decision-to-cease-providing-bootloader-unlocking-codes/topicId_41529/），这使得root变得更加复杂和昂贵。这个bug是否被用作root社区开发的链的一部分还有待观察。
这项研究是由基于华为的漏洞赏金计划。我们要感谢华为PSIRT在处理这个问题上的帮助，慷慨的奖金和公开披露细节的态度。
原文始发于微信公众号（军机故阁）：华为主题管理RCE
