Android MTE技术详解

2024-01-30 10:44
文章标签 android 技术 详解 mte

本文主要是介绍Android MTE技术详解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.MTE概念

        MTE（内存标记扩展）是ARM v8.5-A新增的一项缓解内存安全的机制。在Android Linux现有的安全机制中，类似的机制有ASAN、HWSAN。但两者因为性能开销代价高昂，不适用于广泛部署（仅调试使用）。MTE当前带来了一种高性能、可扩展的硬件解决方案，可降低以不安全语言编写的代码中可能存在的内存安全违规风险。

注：MTE不仅可用在研发自测、内存问题调试，也可以用于Fuzz。

2.MTE支持条件

ARM解释： v8.5及以上

Qcom平台解释：ARM v9（MSM8450）以上

Android解释：Android对MTE的支持将在2021年/2022年初发布带有MTE的芯片时完成。截至于2023年底，最新的旗舰设备（Pixel、OPPO）开发者选项中已具备MTE功能。

3.MTE的开关

        内核层CONFIG_ARM64_MTE=y时开启，此Kconfig由平台根据环境自行控制，无需工程师手动开关。依赖情况如下：

1687config ARM64_MTE1688 bool "Memory Tagging Extension support"1689 default y1690 depends on ARM64_AS_HAS_MTE && ARM64_TAGGED_ADDR_ABI1691 depends on AS_HAS_ARMV8_51692 # Required for tag checking in the uaccess routines1693 depends on ARM64_PAN1694 depends on AS_HAS_LSE_ATOMICS1695 select ARCH_USES_HIGH_VMA_FLAGS1696 help

        Google Play中也提供了APP（Sanitizer Test APP[外网，需要科学上网]）可用于测试MTE，例如：

4.MTE检测目标

MTE认为内存安全违规主要分2种：空间安全、时间安全。

  • 空间安全：

对象在真实边界之外被访问，例如溢出、越界等。可被利用来改变函数指针、保存寄存器等目标地址。

  • 时间安全：

在对象引用的内存释放、过期后使用。例如UAF等，攻击者可以放置一个新的恶意对象来代替预期目标。

下图是两类内存违规的代码表视图：

5.MTE的检测原理

  • 总体思路

        MTE实现了对内存的锁和密钥的验证关系，通过在指针上增加密钥，在内存中加入锁。在指针访问内存时，密钥与锁进行验证。如果匹配，则允许内存访问；否则访问会被记录、拦截。通过这种方式来检测、捕捉内存安全问题。整体逻辑如下图：

  • 技术实现

        ARM64 架构使用64位指针来寻址内存。其中通常有48~52位被硬件实际使用（如果由开启large-address-space，则是52位）。所以理论上有12-16位是预留的。ARM架构一直有“TOP BYTE IGNORE”高字节忽略的功能，允许软件在虚拟地址的最高字节中存储任意数据，但直到MTE前，这些位依然是没有使用。

        MTE允许在虚拟地址的59-56位（即最上层字节的低4位）存储一个key作为密钥。也会将这个密钥与一个或多个16字节的内存范围关联（单独存储作为“锁”）。当一个指针简介访问此内存区域时，存储在指针中的密钥会与指针引用内存的关联密钥进行校验。

  • 密钥来源

        密钥可以由应用程序管理（keymaster）产生，也可以由CPU随机生成。

6.MTE的实际效果

        以2020年修复libjpeg-trubo库漏洞CVE-2020-13790为例。此漏洞是JPEG图像编解码器，在加载格式错误的img文件时导致的堆缓冲区溢出。以下是MTE开启时，漏洞触发的情景：

可以看到，在漏洞复现时，MTE轻松的捕获到，进程会因为分段错误导致中止。故障的存储会通过logcat打印。从图中可以看到：

  • 奔溃的原因：MTE
  • 崩溃的类型：Buffer Overflow
  • 堆的大小以及溢出的大小:104 bytes right of a 16151-byte
  • 问题地址：pc指针（00000056d2240ddc）
  • 进程id：pid=187，tid=187
  • CPU寄存器信息
  • 堆栈的回溯信息

通过addr2line解析pc指针，可以找到问题出现的地址：

7.MTE的处理措施

        当PROT_MTE（相关特性：页表允许MTE分配标签）已开启，并且检测出异常时，有三种不同的选项：

  • Ignore模式（PR_MTE_TCF_NONE）：这是默认模式。CPU和内核将忽略MTE检测错误；如果未设置，也默认此选项。
  • 同步模式（PR_MTE_TCF_SYNC）：内核引发SIGSEGV同步，并且引发SEGV_MTESERR和si_code=fauly-address。并且内存访问会被拦截，如果SIGSEGV被阻塞或忽略，则包含的进程将通过coredump中止。
  • 异步模式（PR_MTE_TCF_ASYNC）：在一个或多个线程检测错误后内核引发SIGSEGV，并设置SEGV_MTAERR和si_code=0；

8.MTE的性能开销

以上是官方给出的性能开销结论：

同步模式：能够识别精确指令和地址，但对性能开销较大；

异步模式：成本更低，再测试工作负载和基准测试中，性能开销估计为：1%~2%，但异步检测提供是失败信息可能不太准确，但它可以提供一些缓解错误信息并用于分析，以便缩小排查范围。

9.上手实效

        据2023年8月，Google Project Zero发布的一篇博文《Fitst handset with MTE on market》呈现，博主在Pixel 8上开启了MTE，正常日常使用中未发现任何异常，也没有感受到性能受到影响。

        作为世界顶级安全团队的Zero，自然也编写了一个具备OOB的Poc进行测试，源码如下：

extern "C" JNIEXPORT jstring JNICALLJava_com_example_mtetestapplication_MainActivity_stringFromJNI(JNIEnv* env,jobject /* this */) {char* ptr = strdup("test string");free(ptr);// Use-after-free when ptr is accessed below.return env->NewStringUTF(ptr);}

测试的结果如下（视频请参考原始地址），以下仅为logcat打印，可以明显看到崩溃原因是testapplication程序发生了UAF。

EBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***DEBUG   : Build fingerprint: 'google/shiba/shiba:14/UD1A.230803.041/10808477:user/release-keys'DEBUG   : Revision: 'MP1.0'DEBUG   : ABI: 'arm64'DEBUG   : Timestamp: 2023-10-24 16:56:32.092532886+0200DEBUG   : Process uptime: 2sDEBUG   : Cmdline: com.example.mtetestapplicationDEBUG   : pid: 24147, tid: 24147, name: testapplication  >>> com.example.mtetestapplication <<<DEBUG   : uid: 10292DEBUG   : tagged_addr_ctrl: 000000000007fff3 (PR_TAGGED_ADDR_ENABLE, PR_MTE_TCF_SYNC, mask 0xfffe)DEBUG   : pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)DEBUG   : signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0b000072afa9f790DEBUG   :     x0  0000000000000001  x1  0000007fe384c2e0  x2  0000000000000075  x3  00000072aae969acDEBUG   :     x4  0000007fe384c308  x5  0000000000000004  x6  7274732074736574  x7  00676e6972747320DEBUG   :     x8  0000000000000020  x9  00000072ab1867e0  x10 000000000000050c  x11 00000072aaed0af4DEBUG   :     x12 00000072aaed0ca8  x13 31106e3dee7fb177  x14 ffffffffffffffff  x15 00000000ebad6a89DEBUG   :     x16 0000000000000001  x17 000000722ff047b8  x18 00000075740fe000  x19 0000007fe384c2d0DEBUG   :     x20 0000007fe384c308  x21 00000072aae969ac  x22 0000007fe384c2e0  x23 070000741fa897b0DEBUG   :     x24 0b000072afa9f790  x25 00000072aaed0c18  x26 0000000000000001  x27 000000754a5fae40DEBUG   :     x28 0000007573c00000  x29 0000007fe384c260DEBUG   :     lr  00000072ab35e7ac  sp  0000007fe384be30  pc  00000072ab1867ec  pst 0000000080001000DEBUG   : 98 total framesDEBUG   : backtrace:DEBUG   :       #00 pc 00000000003867ec  /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::(anonymous namespace)::JniValueType*) (.__uniq.99033978352804627313491551960229047428)+1636) (BuildId: a5fcf27f4a71b07dff05c648ad58e3cd)DEBUG   :       #01 pc 000000000055e7a8  /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::CheckJNI::NewStringUTF(_JNIEnv*, char const*) (.__uniq.99033978352804627313491551960229047428.llvm.6178811259984417487)+160) (BuildId: a5fcf27f4a71b07dff05c648ad58e3cd)DEBUG   :       #02 pc 00000000000017dc  /data/app/~~lgGoAt3gB6oojf3IWXi-KQ==/com.example.mtetestapplication-k4Yl4oMx9PEbfuvTEkjqFg==/base.apk!libmtetestapplication.so (offset 0x1000) (_JNIEnv::NewStringUTF(char const*)+36) (BuildId: f60a9970a8a46ff7949a5c8e41d0ece51e47d82c)...DEBUG   : Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.DEBUG   : Cause: [MTE]: Use After Free, 0 bytes into a 12-byte allocation at 0x72afa9f790DEBUG   : deallocated by thread 24147:DEBUG   :       #00 pc 000000000005e800  /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)+496) (BuildId: a017f07431ff6692304a0cae225962fb)DEBUG   :       #01 pc 0000000000057ba4  /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+212) (BuildId: a017f07431ff6692304a0cae225962fb)DEBUG   :       #02 pc 000000000000179c  /data/app/~~lgGoAt3gB6oojf3IWXi-KQ==/com.example.mtetestapplication-k4Yl4oMx9PEbfuvTEkjqFg==/base.apk!libmtetestapplication.so (offset 0x1000) (Java_com_example_mtetestapplication_MainActivity_stringFromJNI+40) (BuildId: f60a9970a8a46ff7949a5c8e41d0ece51e47d82c)

  10.结论

        从目前看来，启用MTE在性能、续航上的削弱并不明显，但在安全上的提升十分显著。是这些年来继CFI后最重要的商用安全特性（小编自己评的，如果不准确，请不要喷我）。许多0-click的攻击面都会涉及大量C/C++的安全问题。当前MTE也不是内存安全的最终答案，开启后能够提高安全性，但不意味着安全万无一失，

11.参考资料

参考资料链接
Kernel 5.15.0-rcl MTEhttps://www.kernel.org/doc/html/latest/arm64/memory-tagging-extension.html
Tools and SoftwareTools and Software
ARM Developer MTELWN：Arm64的内存标记扩展功能！-CSDN博客
CSDN LWN：ARM64的内存标记扩展功能https://developer.arm.com/architectures/cpu-architecture/a-profile?&_ga=2.256687755.1292256680.1566735535-2019613222.1563850500#mte
ARM MTE白皮书https://www.wwwbuild.net/androidperf/74222.html

这篇关于Android MTE技术详解的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/659981。

相关文章

C++使用栈实现括号匹配的代码详解

C++使用栈实现括号匹配的代码详解

《C++使用栈实现括号匹配的代码详解》在编程中,括号匹配是一个常见问题,尤其是在处理数学表达式、编译器解析等任务时,栈是一种非常适合处理此类问题的数据结构,能够精确地管理括号的匹配问题,本文将通过C+... 目录引言问题描述代码讲解代码解析栈的状态表示测试总结引言在编程中，括号匹配是一个常见问题，尤其是在
阅读更多...
Debezium 与 Apache Kafka 的集成方式步骤详解

Debezium 与 Apache Kafka 的集成方式步骤详解

《Debezium与ApacheKafka的集成方式步骤详解》本文详细介绍了如何将Debezium与ApacheKafka集成,包括集成概述、步骤、注意事项等,通过KafkaConnect,D... 目录一、集成概述二、集成步骤1. 准备 Kafka 环境2. 配置 Kafka Connect3. 安装 D
阅读更多...
Java中ArrayList和LinkedList有什么区别举例详解

Java中ArrayList和LinkedList有什么区别举例详解

《Java中ArrayList和LinkedList有什么区别举例详解》：本文主要介绍Java中ArrayList和LinkedList区别的相关资料,包括数据结构特性、核心操作性能、内存与GC影... 目录一、底层数据结构二、核心操作性能对比三、内存与 GC 影响四、扩容机制五、线程安全与并发方案六、工程
阅读更多...
Android 悬浮窗开发示例((动态权限请求 | 前台服务和通知 | 悬浮窗创建 )

Android 悬浮窗开发示例((动态权限请求 | 前台服务和通知 | 悬浮窗创建 )

《Android悬浮窗开发示例((动态权限请求|前台服务和通知|悬浮窗创建)》本文介绍了Android悬浮窗的实现效果,包括动态权限请求、前台服务和通知的使用,悬浮窗权限需要动态申请并引导... 目录一、悬浮窗 动态权限请求1、动态请求权限2、悬浮窗权限说明3、检查动态权限4、申请动态权限5、权限设置完毕后
阅读更多...
Spring Cloud LoadBalancer 负载均衡详解

Spring Cloud LoadBalancer 负载均衡详解

《SpringCloudLoadBalancer负载均衡详解》本文介绍了如何在SpringCloud中使用SpringCloudLoadBalancer实现客户端负载均衡,并详细讲解了轮询策略和... 目录1. 在 idea 上运行多个服务2. 问题引入3. 负载均衡4. Spring Cloud Load
阅读更多...
Springboot中分析SQL性能的两种方式详解

Springboot中分析SQL性能的两种方式详解

《Springboot中分析SQL性能的两种方式详解》文章介绍了SQL性能分析的两种方式：MyBatis-Plus性能分析插件和p6spy框架,MyBatis-Plus插件配置简单,适用于开发和测试环... 目录SQL性能分析的两种方式:功能介绍实现方式:实现步骤:SQL性能分析的两种方式:功能介绍记录
阅读更多...
在 Spring Boot 中使用 @Autowired和 @Bean注解的示例详解

在 Spring Boot 中使用 @Autowired和 @Bean注解的示例详解

《在SpringBoot中使用@Autowired和@Bean注解的示例详解》本文通过一个示例演示了如何在SpringBoot中使用@Autowired和@Bean注解进行依赖注入和Bean... 目录在 Spring Boot 中使用 @Autowired 和 @Bean 注解示例背景1. 定义 Stud
阅读更多...
如何通过海康威视设备网络SDK进行Java二次开发摄像头车牌识别详解

如何通过海康威视设备网络SDK进行Java二次开发摄像头车牌识别详解

《如何通过海康威视设备网络SDK进行Java二次开发摄像头车牌识别详解》：本文主要介绍如何通过海康威视设备网络SDK进行Java二次开发摄像头车牌识别的相关资料,描述了如何使用海康威视设备网络SD... 目录前言开发流程问题和解决方案dll库加载不到的问题老旧版本sdk不兼容的问题关键实现流程总结前言作为
阅读更多...
SQL 中多表查询的常见连接方式详解

SQL 中多表查询的常见连接方式详解

《SQL中多表查询的常见连接方式详解》本文介绍SQL中多表查询的常见连接方式,包括内连接（INNERJOIN）、左连接（LEFTJOIN）、右连接（RIGHTJOIN）、全外连接（FULLOUTER... 目录一、连接类型图表（ASCII 形式）二、前置代码（创建示例表）三、连接方式代码示例1. 内连接（I
阅读更多...
Go路由注册方法详解

Go路由注册方法详解

《Go路由注册方法详解》Go语言中,http.NewServeMux()和http.HandleFunc()是两种不同的路由注册方式,前者创建独立的ServeMux实例,适合模块化和分层路由,灵活性高... 目录Go路由注册方法1. 路由注册的方式2. 路由器的独立性3. 灵活性4. 启动服务器的方式5.
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2