原创 | 黑帽大会议题解读 BadAlloc内存分配漏洞致数百万设备易受攻击

  • A+
所属分类:安全新闻

作者 | 绿盟科技格物实验室 潘雨晨 [email protected]

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

2021年8月5日,来自微软Azure Defender for IoT 团队的研究员Omri Ben-Bassat 和 Tamir Ariel,在 BlackHat USA 2021 上分享了以内存分配程序漏洞BadAlloc为主题的演讲。本文将和大家一起来看看议题中涉及的内容。

一.  漏洞简介

“BadAlloc”其实是一类漏洞的代号,这些漏洞均与整型溢出相关,具体来说漏洞存在于各类流行的内存分配程序的核心函数(如malloc和calloc)中。BadAlloc漏洞影响诸多广泛使用的实时操作系统(如 VxWorks, FreeRTOS, eCos),标准C库(如,newlib, uClibc, Linux klibc),物联网设备SDK(如,谷歌云物联网SDK, 德州仪器 SimpleLink SDK)和其他自内存管理应用(如,Redis)。其中一些漏洞最早可追溯到90年代早期,它们共同影响着全球数百万台设备,而且尤其是物联网和嵌入式设备。

据微软博客上介绍,攻击者利用这些漏洞可绕过安全控制,在受影响系统上执行恶意代码或导致系统崩溃。这些远程代码执行 (RCE) 漏洞涵盖超过 25 个 CVE,并影响广泛的领域,从消费者、医疗物联网到工业物联网、运营技术 (OT) 和工业控制系统。鉴于 IoT 和 OT 设备的普遍性,这些漏洞如果被成功利用,将成为各种组织的重大潜在风险。

二.  受影响产品

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

通过CISA 发布的通告整理得到如下受影响设备的信息,具体厂商修复情况详见:https://us-cert.cisa.gov/ics/advisories/icsa-21-119-04。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

三.  基于堆的整型溢出简述

3.1 整型溢出

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

整数分为有符号和无符号两种类型,有符号数以最高位作为其符号位,即正整数最高位为0,负整数最高位为1,而无符号数无此类情况,它的取值范围是非负数。不同类型的整数在内存中均有不同的固定取值范围,当我们向其存储的数值超过该类型整数的最大值,就会导致整型溢出,比如 unsigned short 的存储范围是 0 ~ 65535 ,但当存储的值超过 65535 时,数据就会截断,例如输入 65536,系统就会识别为 0。

VC 6.0 中定义的整数变量取值范围:

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

对于无符号整型unsigned int来说,如果它被赋予了最大值 4294967295(0xFFFFFFFF),那么如果程序中有其他操作使其再加上一个 8,那么最终实际上将会得到 7。乘法也是类似的:

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

3.2 堆内存分配

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

通常在动态开辟内存时,会使用 malloc 等函数在堆区开辟空间,分配器将通过特定的数据结构组织堆区的数据块。上图所展示的是分配器通过单/双链表管理空闲内存。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

假如我们通过 malloc 申请一块 1024 字节大小的内存,那么实际分配到的块大小是多少呢?是 Size 的长度 8 加上申请空间大小 1024,块大小是 1032。再考虑另一种情况,假如我们现在申请一块非常大的空间呢,比如申请大小4,294,967,295(= 232 − 1),最终实际得到的块大小会是多少呢?

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

最终只会得到 7。那么这样会产生什么问题呢,下面看一个例子:

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

这是一个简单的程序,其中会根据用户所提供的参数 size 利用 malloc 申请一块空间,如果申请成功,则会执行 memcpy ,从用户提供的数据 user_data 中复制 size 长度的内容到申请好的空间中。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

正常用户传入的参数如上图所示,经过程序处理会返回 OK。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

那假如一个用户传入的 size 很大,比如想要申请 4294967295字节的空间,根据不同的系统,例如在Windows下32位程序如果单纯看地址空间能有4G左右的内存可用,不过实际上系统会把其中2G的地址留给内核使用,所以理想情况下程序最大能用2G的内存。那么程序执行时内存申请会失败,最终返回 Sorry。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

那是否可能存在恶意用户申请巨大空间时成功呢?答案是肯定的,这也就是本次漏洞的关键点所在,一些产品中的内存分配函数由于存在整型溢出漏洞,当用户申请不合理的巨大内存空间时,最终会返回给用户一个指向极小内存空间的指针。那么当程序中对该块内存进行操作时,就极有可能造成堆溢出从而使程序崩溃或被执行代码。

下面就以 FreeRTOS 中的漏洞为例,来看看 BadAlloc的实际情况。

四.  FreeRTOS漏洞实例

CVE-2021-31571和CVE-2021-31572是存在于Amazon Free RTOS  10.4.3之前版本中的整型溢出漏洞。

问题出现在它的内核代码:

https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/224。

4.1 补丁代码分析

https://github.com/FreeRTOS/FreeRTOS-Kernel/commit/c7a9a01c94987082b223d3e59969ede64363da63 中显示总共有 4 个文件做了改动,分别是 heap_1.c,heap_2.c, heap_4.c和heap_5.c。

FreeRTOS对于pvPortMalloc()和vPortFree()提供了5种实现。FreeRTOS应用程序可以使用其中的一种,或者使用自己的实现。

5种实现分别在heap_1.c,heap_2.c,heap_3.c,heap_4.c和heap_5.c文件中,都存在于文件夹FreeRTOS/Source/portable/MemMang下。为了向后兼容性,Heap_2保留在FreeRTOS发行版中,但是不推荐在新设计使用它。可以考虑使用heap_4,heap_4是heap_2增强版。

Heap_2.c还是通过configTOTAL_HEAP_SIZE来定义堆的大小,它使用最佳匹配算法来分配内存,并且与heap_1不同,它允许释放内存。同样,数组是静态声明的,因此会使应用程序看起来消耗大量RAM。

接下来看代码中为了修复漏洞做出的改动:

在 portable/MemMang/heap_1.c 文件中pvPortMalloc()函数里的两处修改:

1、可能出现溢出的变量是 xWantedSize,因为在程序中会给这个变量做加法,修改之后,会在它做自加之前,判断一下它加上 ( portBYTE_ALIGNMENT - ( xWantedSize & portBYTE_ALIGNMENT_MASK ) ) 之后会不会溢出。

2、还是和 xWantedSize 相关,去检查它是否大于 0。

那么现在的疑问是:

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

在 portable/MemMang/heap_2.c 文件中pvPortMalloc()函数里的两处修改:

1、在执行 xWantedSize += heapSTRUCT_SIZE; 之前增加了校验检查 ( xWantedSize + heapSTRUCT_SIZE ) > xWantedSize,防止 xWantedSize 越界。

2、执行内存字节数对齐前,增加xWantedSize + ( portBYTE_ALIGNMENT - ( xWantedSize & portBYTE_ALIGNMENT_MASK ) ) > xWantedSize 的校验。

在 portable/MemMang/heap_4.c 文件中pvPortMalloc()函数里的两处修改:

1、在执行 xWantedSize += xHeapStructSize; 之前增加了校验检查 ( xWantedSize + xHeapStructSize ) > xWantedSize ,防止 xWantedSize 越界。

2、执行内存字节数对齐前,增加 xWantedSize + ( portBYTE_ALIGNMENT - ( xWantedSize & portBYTE_ALIGNMENT_MASK ) ) > xWantedSize 的校验。

在 portable/MemMang/heap_5.c 文件中 pvPortMalloc() 函数里的两处修改:

1、在执行 xWantedSize += xHeapStructSize; 之前增加了校验检查 ( xWantedSize + xHeapStructSize ) > xWantedSize ,防止 xWantedSize 越界。

2、执行内存字节数对齐前,增加 xWantedSize + ( portBYTE_ALIGNMENT - ( xWantedSize & portBYTE_ALIGNMENT_MASK ) ) > xWantedSize 的校验。

根据 https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/224 中的描述,修改增加了对 heap 的边界检查,如果请求的内存块的大小介于 4,294,967,288 和 4,294,967,296 字节之间,则有可能发生溢出。

FreeRTOS官网上安全更新中的通告:

https://www.freertos.org/security/security_updates.html。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

在queue.c 中查找调用了 pvPortMalloc() 函数的地方,只有一处,是当 configSUPPORT_DYNAMIC_ALLOCATION 为1的时候,xQueueGenericCreate 函数中调用了 pvPortMalloc。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

这样看来应该就可以触发 pvPortMalloc 中的整型溢出漏洞了,接下来想要验证申请超大size 内存时程序会出现什么异常,于是决定从搞清以下几个问题来入手:

1、xQueueGenericCreate 是什么作用;

2、它调用 pvPortMalloc 时传入的参数从哪里来且如何控制;

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

静态代码分析的差不多了,现在知道了整型溢出漏洞存在的位置,还知道了要触发该漏洞需要调用的函数。接下来通过动态调试来进一步分析,不过要调试 FreeRTOS 的代码,首先来对 FreeRTOS 大致了解一下。

4.2  FreeRTOS简介

RTOS 全称是 Real Time Operating System,中文就是实时操作系统。RTOS 不是指某一个确定的系统,而是指一类系统。比如 uC/OS,FreeRTOS,RTX,RT-Thread 等这些都是 RTOS 类操作系统。

FreeRTOS 是 RTOS 系统的一种,FreeRTOS 十分小巧,可以在资源有限的微控制器中运行,当然,FreeRTOS 不仅局限于在微控制器中使用。但从文件数量上来看 FreeRTOS 要比uC/OSII 和 uC/OSIII 小的多。通常情况下内核占用 4k-9k 字节的空间。许多半导体厂商产品的 SDK(Software Development Kit—软件开发工具包)包就使用 FreeRTOS 作为其操作系统,尤其是 WIFI、蓝牙这些带协议栈的芯片或模块。

而且FreeRTOS 免费、开放源码,文档齐全。FreeRTOS可以被移植到很多不同架构的处理器和编译器上。每一个RTOS移植都附带一个已经配置好的演示例程,可以方便快速启动开发。更好的是,每个演示例程都附带一个说明网页,提供如何定位RTOS演示工程源代码、如何编译演示例程、如何配置硬件平台的全部信息。

在 https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS/Demo 中可以看到。

4.3  FreeRTOS案例调试

本次为了方便,选取了可以在 Windows 平台上运行的 FreeRTOS 示例程序。示例详见https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS/Demo/WIN32-MSVC 。

首先从 github 上下载了 FreeRTOS v10.4.1的源码,这个版本存在漏洞,而且离最新版本也比较近。下载之后,解压缩,然后在…FreeRTOSDemoWIN32-MSVC目录中,即可看到 Win32-MSVC 的例子。用 Visual Studio 2019(2010及以上的版本都可以)打开 WIN32.sln文件。

官网上有提供 Demo 的介绍:在https://www.freertos.org/a00090.html 选择设备 x86 / Windows Simulator ;

在 https://www.freertos.org/FreeRTOS-Windows-Simulator-Emulator-for-Visual-Studio-and-Eclipse-MingW.html 中即可看到对整个示例程序的完整说明。

大致来说,程序中main 函数会根据mainCREATE_SIMPLE_BLINKY_DEMO_ONLY 的取值来决定是执行 main_blinky() 还是 main_full() 函数。我们其实只关注怎么在程序中调用 xQueueCreate,所以先看比较简单的 main_blinky()。main_blinky() 中部分代码如下图,其中就有调用到和漏洞相关的 xQueueCreate 函数,在调试的时候它的参数我们可控。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

其中的参数 mainQUEUE_LENGTH表示队列一次可以容纳的项目数。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

根据官网安全通告提示,heap_2.c 中存在可利用问题,所以将原先项目中的heap_5.c 移除,从 FreeRTOSSourceportableMemMang 中找到 heap_2.c 替换进去。看下图,在heap_2.c 中,传入的参数会加上 heapSTRUCT_SIZE,通过调试可知道其值是7。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

那么思路就清晰了:为了使在pvPortMalloc 中 xWantedSize + 7 >= 4294967296,就需要保证 xWantedSize >= 4294967289;

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

也就是需要sizeof( Queue_t ) + xQueueSizeInBytes >= 4294967289;sizeof( Queue_t ) 经过调试得到是 84;

所以需要 xQueueSizeInBytes >= 4,294,967,205;

最终只要xQueueSizeInBytes = uxQueueLength * uxItemSize >= 4,294,967,205即可。如果 uxItemSize 保持 sizeof( uint32_t ) 不变,可为 uxQueueLength 赋值为 1,073,741,802。当uxQueueLength为1,073,741,802时, pvPortMalloc中申请内存时获取到的大小实际为 4。

如此编译好的程序在 vs 中调试运行会报错。将程序编译 Release 版本,在 windbg 中打开并运行,在命令行输入 g 命令并执行,进程出现异常:

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

五.  受影响的其他产品

5.1  VxWorks

看 VxWorks 5.1 中的漏洞代码:

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

和 calloc 这个内存分配程序中的处理流程有关。

5.2  Klibc

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

5.3  德州仪器“SimpleLink”SDK

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

可以看到常用SimpleLink组件中包含了之前介绍过的 FreeRTOS。

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

在执行内存分配时,最终调用到的 FreeRTOS 中的 heap_4.c。

SimpleLink 中的 Calloc 是安全的,它里面有执行对溢出的检查,但是Malloc 是不安全的:

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

六.  漏洞缓解措施

BadAlloc 系列漏洞影响范围广泛,必须被用户和受影响软件厂商重视起来,以下是微软提供的一些缓解措施:

1. 按照供应商的说明,及时为受影响的产品打上补丁。

2. 如果无法修补,请加强监控。由于大多数老版 IoT 和 OT 设备不支持代理,因此请使用 IoT/OT 感知网络检测和响应 (NDR) 解决方案来自动发现和持续监控设备异常或未经授权的行为,例如发现到与不熟悉的本地或远程主机通信。这些是为 IoT/OT 实施零信任策略的基本要素。

3. 通过消除与 OT 控制系统不必要的互联网连接来减少攻击面,并在需要远程访问时使用多因素身份验证 (MFA) 实施 VPN 访问。当然VPN 设备也可能存在漏洞,应更新到可用的最新版本。

4. 网络分段对于零信任很重要,因为它限制了攻击者在初始入侵后横向移动并破坏系统的能力。特别是物联网设备和 OT 网络应使用防火墙与企业 IT 网络隔离。

5. 建议检查程序中使用到的如下函数的实现:malloc、calloc、realloc、memalign、valloc、pvalloc、aligned_alloc。

一些标准C库中缓解技术案例如下:

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

参考链接:

1、blackhat官网议题页面

https://www.blackhat.com/us-21/briefings/schedule/#error-badalloc---broken-memory-allocators-led-to-millions-of-vulnerable-iot-and-embedded-devices-23135

2、微软博客

https://msrc-blog.microsoft.com/2021/04/29/badalloc-memory-allocation-vulnerabilities-could-affect-wide-range-of-iot-and-ot-devices-in-industrial-medical-and-enterprise-networks//

3、后端 FreeRTOS 队列

https://www.dazhuanlan.com/jiangbindtc/topics/1004098

https://blog.csdn.net/qq_37634122/article/details/104283673

4、FreeRTOS基础篇系列

https://blog.csdn.net/zhzht19861011/category_9265276.html  


转载请注明来源:关键基础设施安全应急响应中心
“投稿联系方式:010-82992251   [email protected]
原创 | 黑帽大会议题解读  BadAlloc内存分配漏洞致数百万设备易受攻击

本文始发于微信公众号(关键基础设施安全应急响应中心):原创 | 黑帽大会议题解读 BadAlloc内存分配漏洞致数百万设备易受攻击

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: