近年来，移动可信执行环境（TEE, ARM TrustZone）的应用逐步增长。新思科技网络安全研究中心(CyRC)对TEE的应用安全进行了研究分析，其中的一个发现涉及到一加手机OnePlus 7 Pro Advanced的漏洞。该漏洞可能会导致用户注册指纹信息被泄露。
 
安卓系统指纹认证简介
在安卓6以前并没有一套指纹认证的标准。在安卓6以后，谷歌开始介入，并在“即兼容性定义文档”1中定义了一组指纹认证的要求，随着不断发展，现在已经包括了更多生物识别传感器2。
 
标准化方法是需要在TEE执行涉及生物识别信息的所有敏感操作。根据此规范，与指纹硬件（传感器）的通信只能由运行在安全模式下的CPU进行，这将确保即使在Root（破解超级用户权限）设备上也无法从安卓操作系统（开放执行环境，REE）本身接入传感器。
 
如何在一台被Root过的设备上保护资料？
当安卓设备被Root时，通常意味着解锁引导加载程序，并对闪存中的一个或多个分区进行修改。但是，“解锁引导加载程序”并不是一个完全精确的术语。遵循ARM可信的固件模型启动安卓设备。该模型由多个引导阶段组成3。解锁引导加载程序通常是指该过程的最后阶段，设备的可信环境在启动安卓操作系统影像之前接受检查。TEE在此阶段之前启动。  
 
TEE的运行级别和安全状态比安卓操作协同的内核具有更高的特权。REE无法接入可信执行环境存储器，并且所有的通信都通过安卓操作系统内核中的Secure Monitor Calls进行。
 
谷歌规定哪些数据需要受TEE保护，以及在涉及到生物识别时哪些措施需要在TEE下进行TEE旨在确保用户的指纹数据安全，无论设备是否被Root。
 
当然，漏洞总会“有机可乘”的。您的代码越多，漏洞的数量有可能越多。TEE的好处之一是在该特权级别上运行的代码比在安卓操作系统内核级别上运行的代码少，从而减少攻击面，更容易实现安全性。
  
 
1  https://source.android.com/compatibility/6.0/android-6.0-cdd#7_3_10_fingerprint
2 https://source.android.com/compatibility/9/android-9-cdd.html#7_3_10_biometric_sensors
3 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/CACGCHFE.html
   
 
 
在没有被Root过的设备上，用户智能接入安卓架构公开的生物识别API（应用程序接口）。
   
但是，在一台被Root过的设备上，可以在REE的任何位置发起攻击。  
 
 
您可以继续调用libgf_ud_hal库中已经存在的任何功能。或者，可以调用原始传输，建立共享内存缓冲区，并将输入传递给TEE。
这两种操作的区别在于，前者libgf_ud_hal库中的函数将使用特定于您要调用的命令的专有结构来填充缓冲区，并且它可能已经进行了原始传输；后者，您需要知道在该缓冲区中放入什么以及如何构造该缓冲区，以便TEE按路线发送，并且trustlet（高通的可信应用程序）可以理解它。  
从这开始，缓冲区跨越安卓操作系统内核中一长串的调用，从EL3中的Secure Monitor，S-EL1中的TEE OS，并最终到达S-EL0中的trustlet。
 
一旦此缓冲区到达Trustlet，它将进入“路由”功能（命令处理程序）。此功能检查缓冲区的前几个字节，以找出需要执行trustlet的功能。
   
Trustlet开发人员需要确保其生产的trustlet构建不会向REE公开任何敏感功能。例如，考虑以下我们在trustlet中找到的调试代码。您可以从传感器中转储数据并将其返回到REE：  
或者可以效仿OnePlus 7 Pro的操作，只需在“路由”组件中使此代码不可接入即可。
 
CVE-2020-7958
我们在OnePlus 7 Pro上发现的问题是，通过工厂测试命令处理程序可以使用类似的功能。
 
REE中的逻辑
指纹子系统的REE部分包含在libgf_ud_hal.so共享库中。可通过多种方式获得此共享库文件：
1 从被”root”的设备上，在/ vendor / lib64 /目录下。
2 例如，可以从供应商的软件升级页面下载软件版本（固件）。/ vendor / lib64 /目录的内容可以在vendor.img分区中找到。该分区映像可以作为常规ext2文件系统数据映像挂载。  
libgf_ud_hal.so共享库包含一个名为goodix :: SZCustomizedProductTest :: factoryCaptureImage（）的方法。我们通过逆向工程发现了以下解构的伪代码4：
 
4请注意，我们的逆向工程工作大部分都花在了将无意义的v1，v2和v3 + X变成可读的代码上。对于本文中的所有代码示例都是如此。  
 
TEE命令的结构因命令而异，但重要的是，它包含以下路由信息：
1 目标ID（目标）设置为1003。trustlet将使用它将命令路由到处理具有此目标ID的命令的正确模块。
2 命令ID（cmd_id），为17。此参数将命令路由到trustlet内部模块中的特定分支。
 
请注意，至今我们还没有谈到TEE，我们正在讨论指纹传感器的概念。我们怀疑此库可能是传感器供应商提供的SDK（软件开发工具包）的一部分，而设备供应商（例如OnePlus）对他们使用的硬件传感器仅进行了最小的更改和重新配置。
准备好命令结构后，即可使用goodix :: HalBase :: invokeCommand（）函数与高通提供的TEE通信库libQSEEComAPI.so进行通信。 trustlet中的逻辑
在OnePlus 7 Pro的指纹身份验证信任中，我们通过查看错误处理程序和导出的符号来识别以下路由功能：
   
“模块”在这里迭代，并且将对每个模块执行检查，以查看模块元数据条目是否具有与正在处理的命令的“目标ID”相匹配的“目标ID”。如果有，则将从元数据结构中读取并调用该模块的入口点地址，以便它可以继续处理以下命令：  
 
我们在trustlet中发现了一个名为g_dump_module的符号：  
 
 
该符号实际上指向具有将图像从传感器转储到REE中的功能的模块。但是，该模块不在gf_modules_cmd_entry_point使用的表中：  
这很好：将图像转储组件从命令路由逻辑中排除。
 
但是，这里还有另一个有趣的模块：g_product_test_module。测试代码具有对我们有用的功能并不罕见。在此二进制文件中的字符串中搜索与图像转储有关的所有内容，发现了以下有趣的函数名称：sz_factory_test_capture_image
 
对此，交叉引用图表明，它与产品测试模块有某种联系：  
修复和事后思考
修复措施非常简单：将ID 17的命令处理程序从生产Trustlet中删除。这意味着REE对goodix :: SZCustomizedProductTest :: factoryCaptureImage的调用将失败。
 
构建涉及TEE的敏感功能是一个复杂的过程，多个供应商需要参与，并且要对硬件和软件领域都拥有丰富的知识。集成多个SDK是一个挑战。这些SDK可能在REE和TEE上都具有组件，而要找出像这样不常见的漏洞可能是更大的挑战。我们强烈建议一加手机能够迅速指派合适的团队去解决此问题。
 
我们希望本文能解释Trustlet的内部运作、不同组件如何协同工作以提供可信执行环境，以及如何对其进行攻击。以上为摘要翻译，完整原文请参考：https://www.synopsys.com/blogs/software-security/cve-2020-7958-trustlet-tee-attack/