mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
2024年度全球软件漏洞与威胁情报报告、利用 CVE-2025-0072 绕过 MTE、速修！Kafka Connect爆任意文件读取漏洞，无需授权、信息安全漏洞周报（2025年第23期）、CVE 2024-43570 和 CVE-2024-43535 的报告和 POC、
This commit is contained in:
test committed
1 parent
0de7fed488
commit
0d51120fd4
6 files changed
+673
-1
No files matched your search
@@ -15019,5 +15019,10 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkyNzQzNDI5OQ==&mid=2247486700&idx=1&sn=c4141ed8747a6ddf3958888b71c5899e": "【漏洞预警】Apache Kafka Connect 任意文件读取和服务端请求伪造漏洞(CVE-2025-27817)",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzNzY5OTg2Ng==&mid=2247501170&idx=3&sn=6eb1c5ad37527cefeda8cb6557e090a2": "【漏洞通告】Apache Kafka Broker JNDI远程代码执行漏洞(CVE-2025-27819)",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzNTI4NjU1Mw==&mid=2247485082&idx=1&sn=d864aa242dace84f433eb2fae22e0c69": "2025年5月企业必修安全漏洞清单",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg5NjAxNjc5OQ==&mid=2247484489&idx=1&sn=a947eef1ac5b257d64b7afb09bdcbe3b": "AWS re:Inforce 2025 应用安全议题"
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg5NjAxNjc5OQ==&mid=2247484489&idx=1&sn=a947eef1ac5b257d64b7afb09bdcbe3b": "AWS re:Inforce 2025 应用安全议题",
|
||||
"https://mp.weixin.qq.com/s?__biz=MjM5OTk4MDE2MA==&mid=2655282214&idx=1&sn=0625914fed042db42421a0970a5166c9": "2024年度全球软件漏洞与威胁情报报告",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxMjYyMzkwOA==&mid=2247530717&idx=3&sn=3dda2acd611a02796d17b6fed3a78683": "利用 CVE-2025-0072 绕过 MTE",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg5MTc3ODY4Mw==&mid=2247507787&idx=1&sn=1470dd59fd12731195bf46d75d0e856c": "速修！Kafka Connect爆任意文件读取漏洞，无需授权",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxODY1OTM5OQ==&mid=2651463169&idx=1&sn=4657e8043045aba6ecf5bab93e343ee2": "信息安全漏洞周报（2025年第23期）",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxMjYyMzkwOA==&mid=2247530717&idx=2&sn=2e039d2ebc04cf71f327eb71ea092dba": "CVE 2024-43570 和 CVE-2024-43535 的报告和 POC"
|
||||
}
|
||||
@@ -0,0 +1,59 @@
|
||||
# 2024年度全球软件漏洞与威胁情报报告
|
||||
计算机与网络安全 2025-06-10 23:57
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**扫码加入知识星球****：**
|
||||
**网络安全攻防（HVV）**
|
||||
|
||||
**下载本篇和全套资料**
|
||||
|
||||
****
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
**|**
|
||||
-
|
||||
|
||||
@@ -0,0 +1,93 @@
|
||||
# CVE 2024-43570 和 CVE-2024-43535 的报告和 POC
|
||||
Ots安全 2025-06-11 03:16
|
||||
|
||||
|
||||
|
||||
CVE-2024-43570 简介
|
||||
- 类型：Windows 内核提权漏洞
|
||||
|
||||
- 发布日期：2024年10月8日
|
||||
|
||||
- 影响：攻击者可利用 Windows 内核缺陷，执行任意代码，获取系统管理员权限，可能导致系统完全受损。
|
||||
|
||||
- 受影响系统：Windows 10、Windows 11 及其他使用受影响内核的系统。
|
||||
|
||||
- 缓解措施：立即安装微软发布的补丁，启用安全软件，限制用户权限，谨慎处理未知来源文件。
|
||||
|
||||
- 严重性：高危（具体 CVSS 评级需参考微软公告）。
|
||||
|
||||
CVE-2024-43535 简介
|
||||
- 类型：Windows 内核模式驱动程序提权漏洞
|
||||
|
||||
- 发布日期：2024年10月7日
|
||||
|
||||
- 影响：攻击者可利用内核模式驱动程序缺陷，获取系统高权限，可能安装恶意软件或绕过安全机制。
|
||||
|
||||
- 受影响系统：Windows 10、Windows 11 等。
|
||||
|
||||
- 缓解措施：通过 Windows Update 安装补丁，禁用不必要驱动程序，使用标准用户账户，监控系统行为。
|
||||
|
||||
- 严重性：高危（需参考 NVD 或微软公告）。
|
||||
|
||||
|
||||
|
||||
KTM_POCS
|
||||
|
||||
此 repo 包含CVE 2024-43570和CVE 2024-43535的报告，这两个漏洞是我在 Windows 内核事务管理器驱动程序 tm.sys 中发现的。
|
||||
|
||||
此 repo 还包含我在 OffensiveCon25 演示中的演示中使用的漏洞代码：
|
||||
> Cedric Halbronn 和 Jael Koh 编写的在 Windows 11 KTM 中寻找被忽视的 Cookies 并为它们烘焙漏洞。
|
||||
|
||||
> https://www.youtube.com/watch?v=goEb7eKj660
|
||||
|
||||
> 演示文稿的幻灯片可在此处获取。
|
||||
|
||||
> https://docs.google.com/presentation/d/1M_ziQt6rZA01ghsv0qo7lhqyOLIZYNnV-qjHWun6A1g/edit?usp=sharing
|
||||
|
||||
|
||||
漏洞代码已在 Windows 11 Pro 23H2 226321.4169（九月补丁星期二更新）虚拟机上进行了测试
|
||||
|
||||
|
||||
|
||||
|
||||
时间线
|
||||
|
||||
2024 年 4 月 24 日 - 2024 年 4 月 26 日：tm.sys 研究尝试 [#1]()
|
||||
|
||||
|
||||
2024 年 5 月 18 日 - 2024 年 5 月 20 日：tm.sys 研究尝试 [#2]()
|
||||
|
||||
|
||||
2024 年 6 月 14 日 - 2024 年 7 月 7 日：tm.sys 研究尝试 [#3]()
|
||||
|
||||
|
||||
2024 年 6 月 24 日：向 MSRC 报告 CVE 2024-43570
|
||||
|
||||
2024 年 7 月 7 日：向 MSRC 报告 CVE 2024-43535
|
||||
|
||||
2024 年 7 月 18 日：CVE 2024-43570 漏洞奖励 2000 美元
|
||||
|
||||
2024 年 10 月 5 日：为 CVE 2024-43535 颁发 2000 美元赏金
|
||||
|
||||
2024 年 10 月 8 日：修复 CVE-2024-43570 和 CVE-2024-43535
|
||||
|
||||
|
||||
|
||||
感谢您抽出
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
来阅读本文
|
||||
|
||||
|
||||
|
||||
**点它，分享点赞在看都在这里**
|
||||
|
||||
@@ -0,0 +1,141 @@
|
||||
# 信息安全漏洞周报（2025年第23期）
|
||||
原创 CNNVD CNNVD安全动态 2025-06-11 02:59
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**点击蓝字 关注我们**
|
||||
|
||||
|
||||
|
||||
|
||||
**漏洞情况**
|
||||
|
||||
根据国家信息安全漏洞库（CNNVD）统计，本周（2025年6月2日至2025年6月8日）安全漏洞情况如下：
|
||||
|
||||
**公开漏洞情况**
|
||||
|
||||
本周CNNVD采集安全漏洞854个。
|
||||
|
||||
**接报漏洞情况**
|
||||
|
||||
本周CNNVD接报漏洞7280个，其中信息技术产品漏洞（通用型漏洞）272个，网络信息系统漏洞（事件型漏洞）56个，漏洞平台推送漏洞6952个。
|
||||
|
||||
## 一公开漏洞情况
|
||||
|
||||
|
||||
根据国家信息安全漏洞库（CNNVD）统计，本周新增安全漏洞854个，漏洞新增数量有所上升。从厂商分布来看WordPress基金会新增漏洞最多，有245个；从漏洞类型来看，跨站脚本类的安全漏洞占比最大，达到11.71%。新增漏洞中，超危漏洞42个，高危漏洞211个，中危漏洞558个，低危漏洞43个。
|
||||
|
||||
****
|
||||
（一） 安全漏洞增长数量情况
|
||||
|
||||
|
||||
|
||||
本周CNNVD采集安全漏洞854个。
|
||||
|
||||
|
||||
|
||||
图1 近五周漏洞新增数量统计图
|
||||
|
||||
****
|
||||
（二） 安全漏洞分布情况
|
||||
|
||||
|
||||
|
||||
从厂商分布来看，WordPress基金会新增漏洞最多，有245个。各厂商漏洞数量分布如表1所示。
|
||||
|
||||
表1 新增安全漏洞排名前五厂商统计表
|
||||
|
||||
|
||||
|
||||
本周国内厂商漏洞136个，吉翁电子公司漏洞数量最多，有27个。国内厂商漏洞整体修复率为50.36%。请受影响用户关注厂商修复情况，及时下载补丁修复漏洞。
|
||||
|
||||
从漏洞类型来看，跨站脚本类的安全漏洞占比最大，达到11.71%。漏洞类型统计如表2所示。
|
||||
|
||||
表2 漏洞类型统计表
|
||||
|
||||
|
||||
|
||||
（三） 安全漏洞危害等级与修复情况
|
||||
|
||||
|
||||
|
||||
本周共发布超危漏洞42个，高危漏洞211个，中危漏洞558个，低危漏洞43个。相应修复率分别为50.00%、51.66%、50.72%和23.26%。根据补丁信息统计，合计423个漏洞已有修复补丁发布，整体修复率为49.53%。详细情况如表3所示。
|
||||
|
||||
表3 漏洞危害等级与修复情况
|
||||
|
||||
|
||||
|
||||
（四） 本周重要漏洞实例
|
||||
|
||||
|
||||
|
||||
本周重要漏洞实例如表4所示。
|
||||
|
||||
表4 本期重要漏洞实例
|
||||
|
||||
|
||||
|
||||
**1. WordPress plugin Golo 安全漏洞（CNNVD-202506-147）**
|
||||
|
||||
WordPress和WordPress plugin都是WordPress基金会的产品。WordPress是一套使用PHP语言开发的博客平台。该平台支持在PHP和MySQL的服务器上架设个人博客网站。WordPress plugin是一个应用插件。
|
||||
|
||||
WordPress plugin Golo 1.7.0版本及之前版本存在安全漏洞，该漏洞源于未正确验证用户身份。攻击者利用该漏洞可以提升权限。
|
||||
|
||||
目前厂商已发布升级补丁以修复漏洞，参考链接：
|
||||
|
||||
https://wordpress.org/themes/
|
||||
|
||||
**2. Apache InLong 代码问题漏洞（CNNVD-202506-740）******
|
||||
|
||||
Apache InLong是美国阿帕奇（Apache）基金会的一站式的海量数据集成框架，提供自动化、安全、可靠的数据传输能力。
|
||||
|
||||
Apache InLong 1.13.0版本至2.1.0之前版本存在代码问题漏洞，该漏洞源于反序列化不可信数据。攻击者利用该漏洞可以读取任意文件。
|
||||
|
||||
目前厂商已发布升级补丁以修复漏洞，参考链接：
|
||||
|
||||
https://inlong.apache.org/versions/
|
||||
|
||||
**3. Dell Encryption Admin Utilities 安全漏洞（CNNVD-202506-203）******
|
||||
|
||||
Dell Encryption Admin Utilities是美国戴尔（Dell）公司的一款用于数据加密管理和故障排除的软件。
|
||||
|
||||
Dell Encryption Admin Utilities 11.10.2之前版本存在安全漏洞，该漏洞源于对链接解析不当。攻击者利用该漏洞可以提升权限。
|
||||
|
||||
目前厂商已发布升级补丁以修复漏洞，参考链接：
|
||||
|
||||
https://www.dell.com/support/kbdoc/en-us/000325203/dsa-2025-224
|
||||
|
||||
****
|
||||
## 二漏洞平台推送情况
|
||||
|
||||
|
||||
本周CNNVD接收漏洞平台推送漏洞6952个。
|
||||
|
||||
表5 本周漏洞平台推送情况
|
||||
|
||||
|
||||
|
||||
## 三接报漏洞情况
|
||||
|
||||
|
||||
本周CNNVD接报漏洞328个，其中信息技术产品漏洞（通用型漏洞）272个，网络信息系统漏洞（事件型漏洞）56个。
|
||||
|
||||
表6 本周漏洞报送情况
|
||||
|
||||
|
||||
|
||||
## 四收录漏洞通报情况
|
||||
|
||||
|
||||
本周CNNVD收录漏洞通报126份。
|
||||
|
||||
表7 本周漏洞通报情况
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,244 @@
|
||||
# 利用 CVE-2025-0072 绕过 MTE
|
||||
Ots安全 2025-06-11 03:16
|
||||
|
||||
|
||||
|
||||
这篇文章深入探讨了
|
||||
CVE-2025-0072
|
||||
，一个影响 ARM Mali GPU 驱动的漏洞，作者详细描述了如何利用该漏洞在启用内存标签扩展（Memory Tagging Extension, MTE）的安卓设备上实现任意内核代码执行。以下是文章的核心内容：
|
||||
1. 漏洞背景
|
||||
：
|
||||
|
||||
1. CVE-2025-0072
|
||||
是作者发现并于 2024 年 12 月 12 日报告给 ARM 的一个漏洞，影响使用 Command Stream Frontend (CSF) 架构的新款 ARM Mali GPU，例如 Google Pixel 7、8 和 9 系列。
|
||||
|
||||
1. 该漏洞已于 2025 年 5 月 2 日在 Mali 驱动版本 r54p0 中修复，并包含在安卓 2025 年 5 月的安全更新中。
|
||||
|
||||
1. 文章通过分析 Mali GPU 驱动中的 CSF 队列机制，展示了如何利用漏洞绕过 MTE（一种旨在防止内存腐败的硬件安全特性）并实现内核代码执行。
|
||||
|
||||
1. CSF 队列的工作原理
|
||||
：
|
||||
|
||||
1. CSF 队列是 Mali GPU 驱动中用于用户态与内核态通信的机制，通过
|
||||
kbase_queue
|
||||
和
|
||||
kbase_queue_group
|
||||
对象实现。
|
||||
|
||||
1. 用户通过
|
||||
KBASE_IOCTL_CS_QUEUE_REGISTER
|
||||
和
|
||||
KBASE_IOCTL_CS_QUEUE_GROUP_CREATE
|
||||
等 ioctl 调用创建和绑定队列，分配 GPU 内存并将其映射到用户空间。
|
||||
|
||||
1. 队列绑定后，内存页面存储在
|
||||
queue->phys
|
||||
中，并通过
|
||||
mmap
|
||||
调用映射到用户空间。页面释放通常在用户空间解除映射时触发。
|
||||
|
||||
1. 漏洞利用原理
|
||||
：
|
||||
|
||||
1. 漏洞的核心在于通过多次绑定和解绑
|
||||
kbase_queue
|
||||
操作，操控
|
||||
queue->phys
|
||||
中的内存页面，制造
|
||||
页面使用后释放（use-after-free, UAF）
|
||||
漏洞。
|
||||
|
||||
1. 具体步骤包括：
|
||||
|
||||
1. 通过精心安排内存池操作，作者将释放的页面重新分配为 GPU 上下文的页面表全局目录（PGD），从而允许从用户空间重写 PGD，实现任意内核内存读写和代码执行。
|
||||
|
||||
1. 创建并绑定
|
||||
kbase_queue
|
||||
和
|
||||
kbase_queue_group
|
||||
，分配初始 GPU 内存页面并映射到用户空间。
|
||||
|
||||
1. 终止原始
|
||||
kbase_queue_group
|
||||
，解绑队列。
|
||||
|
||||
1. 将队列绑定到新的
|
||||
kbase_queue_group
|
||||
，分配新的 GPU 内存页面，覆盖
|
||||
queue->phys
|
||||
。
|
||||
|
||||
1. 解除旧用户空间映射，导致新的
|
||||
queue->phys
|
||||
页面被错误释放，但仍可通过新的用户空间映射访问。
|
||||
|
||||
1. 绕过 MTE 的机制
|
||||
：
|
||||
|
||||
1. MTE 是 ARMv8.5-A 架构引入的硬件内存安全特性，通过在指针和内存块中存储标签（tag）来检测内存腐败（如线性溢出或 UAF）。
|
||||
|
||||
1. 该漏洞通过用户空间映射直接访问释放的页面，绕过了 MTE 的检查。原因可能是页面映射通过
|
||||
insert_pfn
|
||||
直接插入用户空间页面表，访问时无需内核解引用，因此未触发 MTE。
|
||||
|
||||
1. 即使页面被释放至内核的 buddy 分配器，MTE 仍未触发，表明用户空间映射的特殊性质可能导致 MTE 失效。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
内存标记扩展 (MTE)是一项高级内存安全功能，旨在使内存损坏漏洞几乎无法被利用。然而，任何缓解措施都不可能做到万无一失，尤其是在底层操作内存的内核代码中。
|
||||
|
||||
去年，我曾撰写过一篇关于 CVE-2023-6241 的文章，该漏洞存在于 ARM 的 Mali GPU 驱动程序中，可使不受信任的 Android 应用绕过 MTE 并获取任意内核代码执行权限。在本文中，我将介绍 CVE-2025-0072：一个最近已修补的漏洞，该漏洞也是我在 ARM 的 Mali GPU 驱动程序中发现的。与上一个漏洞一样，该漏洞也使恶意 Android 应用能够绕过 MTE 并获取任意内核代码执行权限。
|
||||
|
||||
我于 2024 年 12 月 12 日向 Arm 报告了此问题。该问题已在2025 年 5 月 2 日公开发布的Mali 驱动程序版本r54p0中得到修复，并包含在 Android 2025 年 5 月的安全更新中。该漏洞会影响搭载较新 Arm Mali GPU 且采用命令流前端 (CSF ) 架构的设备，例如 Google 的 Pixel 7、8 和 9 系列。我在启用了内核 MTE 的 Pixel 8 上开发并测试了该漏洞利用程序，我相信经过少量修改后，该漏洞应该也适用于 7 和 9。
|
||||
|
||||
接下来深入探讨 CSF 队列的工作原理、我用来利用此漏洞的步骤以及它最终如何绕过 MTE 保护来实现内核代码执行。
|
||||
|
||||
CSF队列的工作原理及其危险性
|
||||
|
||||
具有 CSF 功能的 Arm Mali GPU 通过命令队列与用户空间应用程序通信，这些队列在驱动程序中以kbase_queue对象的形式实现。队列是使用 创建的。要使用创建的 ，首先必须将其绑定到，而 是通过 创建的。可以使用将 A 绑定到。将 a 绑定到时，会创建一个句柄并将其返回给用户应用程序。
|
||||
|
||||
```
|
||||
KBASE_IOCTL_CS_QUEUE_REGISTERioctl kbase_queue kbase_queue_group KBASE_IOCTL_CS_QUEUE_GROUP_CREATEioctl kbase_queue kbase_queue_group KBASE_IOCTL_CS_QUEUE_BINDioctl kbase_queue kbase_queue_group get_user_pages_mmap_handle
|
||||
```
|
||||
|
||||
|
||||
|
||||
```
|
||||
intkbase_csf_queue_bind(struct kbase_context *kctx, union kbase_ioctl_cs_queue_bind *bind){ ...group = find_queue_group(kctx, bind->in.group_handle); queue = find_queue(kctx, bind->in.buffer_gpu_addr); … ret = get_user_pages_mmap_handle(kctx, queue);if (ret) gotoout; bind->out.mmap_handle = queue->handle;group->bound_queues[bind->in.csi_index] = queue; queue->group = group; queue->group_priority = group->priority; queue->csi_index = (s8)bind->in.csi_index; queue->bind_state = KBASE_CSF_QUEUE_BIND_IN_PROGRESS;out: rt_mutex_unlock(&kctx->csf.lock);return ret;}
|
||||
```
|
||||
|
||||
|
||||
此外， 和 之间存储了相互引用kbase_queue_group。queue请注意，调用完成后，queue->bind_state设置为KBASE_CSF_QUEUE_BIND_IN_PROGRESS，表示绑定尚未完成。要完成绑定，用户应用程序必须调用 ，mmap并使用 所返回的句柄ioctl作为文件偏移量。此mmap调用由 处理
|
||||
kbase_csf_cpu_mmap_user_io_pages，它通过 分配 GPU 内存
|
||||
kbase_csf_alloc_command_stream_user_pages并将其映射到用户空间。
|
||||
|
||||
|
||||
```
|
||||
intkbase_csf_alloc_command_stream_user_pages(struct kbase_context *kctx, struct kbase_queue *queue){structkbase_device *kbdev = kctx->kbdev;int ret; lockdep_assert_held(&kctx->csf.lock); ret = kbase_mem_pool_alloc_pages(&kctx->mem_pools.small[KBASE_MEM_GROUP_CSF_IO], KBASEP_NUM_CS_USER_IO_PAGES, queue->phys, false, //<------ 1. kctx->task); ... ret = kernel_map_user_io_pages(kctx, queue); ... get_queue(queue);queue->bind_state = KBASE_CSF_QUEUE_BOUND; mutex_unlock(&kbdev->csf.reg_lock);return0; ...}
|
||||
```
|
||||
|
||||
|
||||
在上述代码片段 1 中，kbase_mem_pool_alloc_pages调用 来从 GPU 内存池分配内存页，这些内存页的地址随后存储在queue->phys字段中。这些内存页随后被映射到用户空间，bind_state队列的 设置为KBASE_CSF_QUEUE_BOUND。仅当映射区域从用户空间取消映射后，才会释放这些内存页。在这种情况下，kbase_csf_free_command_stream_user_pages调用 来通过 释放内存页kbase_mem_pool_free_pages。
|
||||
|
||||
```
|
||||
voidkbase_csf_free_command_stream_user_pages(struct kbase_context *kctx, struct kbase_queue *queue){ kernel_unmap_user_io_pages(kctx, queue); kbase_mem_pool_free_pages(&kctx->mem_pools.small[KBASE_MEM_GROUP_CSF_IO], KBASEP_NUM_CS_USER_IO_PAGES, queue->phys, true, false); ...}
|
||||
```
|
||||
|
||||
|
||||
这将释放存储在 中的页面queue->phys，并且因为这仅在页面从用户空间取消映射时发生，因此它可以防止页面在释放后被访问。
|
||||
|
||||
一个利用想法
|
||||
|
||||
有趣的部分始于我们思考：如果我们在将queue->phys页面映射到用户空间后进行修改，会发生什么？例如，如果我可以kbase_csf_alloc_command_user_pages再次触发将新页面覆盖到queue->phys，并将它们映射到用户空间，然后取消映射先前映射的区域，kbase_csf_free_command_stream_user_pages将被调用以释放 中的页面queue->phys。然而，由于queue->phys被新分配的页面覆盖，我最终陷入了一种情况：在取消映射旧区域的同时，我释放了新页面：
|
||||
|
||||
|
||||
|
||||
在上图中，右侧列表示用户空间中的映射，绿色矩形表示已映射，灰色矩形表示未映射。左侧列表示存储在中的备用页面queue->phys。新queue->phys页面表示当前存储在中的页面queue->phys，旧queue->phys页面表示之前存储但被新页面替换的页面。绿色表示页面处于活动状态，红色表示已被释放。在覆盖queue->phys并取消映射旧区域后，新页面queue->phys将被释放，但仍映射到新的用户区域。这意味着用户空间将可以访问已释放的新queue->phys页面。这便给我带来了页面释放后使用漏洞。
|
||||
|
||||
漏洞
|
||||
|
||||
那么让我们看看如何实现这种情况。首先显而易见的是尝试看看我是否可以kbase_queue使用 多次绑定 KBASE_IOCTL_CS_QUEUE_BIND ioctl。然而，这是不可能的，因为queue->group在绑定之前会检查该字段：
|
||||
|
||||
```
|
||||
intkbase_csf_queue_bind(struct kbase_context *kctx, union kbase_ioctl_cs_queue_bind *bind){ ... if (queue->group || group->bound_queues[bind->in.csi_index]) gotoout; ...}
|
||||
```
|
||||
|
||||
|
||||
kbase_queue绑定后， aqueue->group会被设置为kbase_queue_group它所绑定到的 ，从而防止kbase_queue再次绑定。此外，一旦 akbase_queue被绑定，就无法通过任何 解除绑定ioctl。它可以通过 终止KBASE_IOCTL_CS_QUEUE_TERMINATE，但这也会删除kbase_queue。因此，如果无法从队列重新绑定，那么尝试从 解除绑定又如何呢kbase_queue_group？例如，如果 akbase_queue_group被 终止会发生什么KBASE_IOCTL_CS_QUEUE_GROUP_TERMINATE ioctl？当 akbase_queue_group终止时，作为清理过程的一部分，它会调用kbase_csf_term_descheduled_queue_group来解除它所绑定到的队列的绑定：
|
||||
|
||||
```
|
||||
voidkbase_csf_term_descheduled_queue_group(struct kbase_queue_group *group){ ... for (i = 0; i < max_streams; i++) { structkbase_queue *queue = group->bound_queues[i]; /* The group is already being evicted from the scheduler */ if (queue) unbind_stopped_queue(kctx, queue); } ...}
|
||||
```
|
||||
|
||||
|
||||
然后重置解除绑定queue->group的字段：kbase_queue
|
||||
|
||||
```
|
||||
staticvoidunbind_stopped_queue(struct kbase_context *kctx, struct kbase_queue *queue){ ... if (queue->bind_state != KBASE_CSF_QUEUE_UNBOUND) { ... queue->group->bound_queues[queue->csi_index] = NULL; queue->group = NULL; ... queue->bind_state = KBASE_CSF_QUEUE_UNBOUND; }}
|
||||
```
|
||||
|
||||
|
||||
具体来说，现在允许kbase_queue绑定到另一个kbase_queue_group。这意味着我现在可以按照以下步骤创建一个页面 UAF：
|
||||
1. 创建kbase_queue和kbase_queue_group，然后将 绑定kbase_queue到kbase_queue_group。
|
||||
|
||||
1. 为 中的用户 IO 页面创建 GPU 内存页面，kbase_queue并使用调用将它们映射到用户空间mmap。然后，这些页面将存储在queue->phys的字段中kbase_queue。
|
||||
|
||||
1. 终止kbase_queue_group，这也会解除 的绑定kbase_queue。
|
||||
|
||||
1. 创建另一个kbase_queue_group并将其绑定kbase_queue到这个新组。
|
||||
|
||||
1. 为此处的用户 IO 页面创建新的 GPU 内存页面kbase_queue，并将其映射到用户空间。这些页面现在将覆盖 中的现有页面queue->phys。
|
||||
|
||||
1. 取消映射在步骤 2 中映射的用户空间内存。这将释放页面queue->phys并删除在步骤 2 中创建的用户空间映射。但是，释放的页面现在是在步骤 5 中创建和映射的内存页面，它们仍然映射到用户空间。
|
||||
|
||||
具体来说，这意味着上述步骤 6 中释放的页面仍然可以从用户应用程序访问。通过我之前使用过的技术，我可以将这些释放的页面重用为Mali GPU 的页表全局目录 (PGD) 。
|
||||
|
||||
回顾一下，我们来看看 a 的后备页面kbase_va_region是如何分配的。在为 a 的后备存储分配页面时kbase_va_region，kbase_mem_pool_alloc_pages使用以下函数：
|
||||
|
||||
```
|
||||
intkbase_mem_pool_alloc_pages(struct kbase_mem_pool *pool, size_t nr_4k_pages, struct tagged_addr *pages, bool partial_allowed){ .../* Get pages from this pool */while (nr_from_pool--) { p = kbase_mem_pool_remove_locked(pool); //<------- 1. ... } ...if (i != nr_4k_pages && pool->next_pool) { /* Allocate via next pool */ err = kbase_mem_pool_alloc_pages(pool->next_pool, //<----- 2. nr_4k_pages - i, pages + i, partial_allowed); ... } else { /* Get any remaining pages from kernel */ while (i != nr_4k_pages) { p = kbase_mem_alloc_page(pool); //<------- 3. ... } ... } ...}
|
||||
```
|
||||
|
||||
|
||||
输入参数kbase_mem_pool是一个内存池，由与驱动程序文件关联的 kbase_context 对象管理，用于分配 GPU 内存。正如注释所示，分配实际上是分层进行的。首先，页面将从当前kbase_mem_pool正在使用的内存中分配kbase_mem_pool_remove_locked（上文中的 1）。如果当前内存中没有足够的容量kbase_mem_pool来满足请求，则pool->next_pool使用 来分配页面（上文中的 2）。如果 even 也pool->next_pool没有足够的容量，则kbase_mem_alloc_page使用 直接从内核通过伙伴分配器（内核中的页面分配器）分配页面。
|
||||
|
||||
释放页面时，反方向也会发生同样的操作：kbase_mem_pool_free_pages首先尝试将页面归还给kbase_mem_pool当前 的kbase_context，如果内存池已满，则会尝试将剩余的页面归还给pool->next_pool。如果下一个内存池也已满，则剩余的页面将通过伙伴分配器释放并归还给内核。
|
||||
|
||||
正如我在文章“无内存损坏的内存破坏”中所述，pool->next_poolkbase_context 是一个由 Mali 驱动程序管理并由所有 kbase_context 共享的内存池。它还用于分配GPU 上下文使用的页表全局目录 (PGD)。具体而言，这意味着通过精心安排内存池，可以将已释放的备用页面kbase_va_region重用为 GPU 上下文的 PGD。（阅读有关如何实现此目的的详细信息。）
|
||||
|
||||
一旦释放的页面被重用为 GPU 上下文的 PGD，用户空间映射便可用于从 GPU 重写 PGD。这样一来，任何内核内存（包括内核代码）都可以映射到 GPU，从而允许我重写内核代码，进而执行任意内核代码。这还允许我读写任意内核数据，因此我可以轻松重写进程的凭据以获取 root 权限，并禁用 SELinux。
|
||||
> 查看Pixel 8 的漏洞及其一些设置说明。
|
||||
|
||||
> https://github.com/github/securitylab/tree/main/SecurityExploits/Android/Mali/CVE-2025-0072
|
||||
|
||||
|
||||
这如何绕过 MTE？
|
||||
|
||||
在结束之前，让我们先看看为什么这个漏洞能够绕过内存标记扩展 (MTE) — — 尽管有保护措施应该可以使这种类型的攻击不可能发生。
|
||||
|
||||
内存标记扩展 (MTE) 是较新的 Arm 处理器上的一项安全功能，它使用硬件实现来检查内存损坏。
|
||||
|
||||
Arm64 架构使用 64 位指针访问内存，而大多数应用程序使用的地址空间要小得多（例如 39、48 或 52 位）。64 位指针的最高位实际上未被使用。内存标记的主要思想是使用地址中的这些高位来存储一个“标签”，然后可以使用该标签与与该地址关联的内存块中存储的另一个标签进行校验。
|
||||
|
||||
当发生线性溢出，并使用指针解引用相邻内存块时，指针上的标记很可能与相邻内存块中的标记不同。通过在解引用时检查这些标记，可以检测到这种差异，从而检测到损坏的解引用。对于释放后使用 (UAF) 类型的内存损坏，只要每次释放内存块时清除其标记，并在分配内存块时重新分配新的标记，解引用已释放并回收的对象也会导致指针标记与内存中的标记不一致，从而可以检测到释放后使用 (UAF)。
|
||||
|
||||
|
||||
|
||||
图片来自内存标记扩展：通过Arm 发布的架构增强内存安全性
|
||||
|
||||
内存标记扩展是 ARM 架构v8.5a 版本中引入的指令集，旨在加速硬件对内存进行标记和检查的过程。这使得在实际应用中使用内存标记成为可能。在支持硬件加速指令的架构中，仍然需要内存分配器中的软件支持才能调用内存标记指令。在 Linux 内核中，用于分配内核对象的SLUB 分配器和用于分配内存页的伙伴分配器均支持内存标记。
|
||||
> 有兴趣了解更多细节的读者可以参考这篇文章以及Arm发布的白皮书。
|
||||
|
||||
> https://lwn.net/Articles/834289/
|
||||
|
||||
|
||||
正如我在引言中提到的，此漏洞能够绕过 MTE。然而，与我之前报告的漏洞（通过 GPU 访问已释放的内存页面）不同，此漏洞通过用户空间映射访问已释放的内存页面。由于页面分配和取消引用受 MTE 保护，因此此漏洞能够绕过 MTE 或许有些令人惊讶。最初，我认为这是因为漏洞涉及的内存页面由 管理kbase_mem_pool，而 是 Mali GPU 驱动程序使用的自定义内存池。在此漏洞中，被重用为 PGD 的已释放内存页面只是被返回到由 管理的内存池kbase_mem_pool，然后从该内存池再次分配。因此，该页面从未真正被伙伴分配器释放，因此不受 MTE 保护。尽管如此，我还是决定尝试正确释放该页面并将其返回给伙伴分配器。令我惊讶的是，即使在伙伴分配器释放该页面后访问该页面，MTE 也不会触发。经过一些实验和源代码阅读，似乎由mgm_vmf_insert_pfn_protin创建的页面映射kbase_csf_user_io_pages_vm_fault（用于在内存页面释放后访问该页面）最终会用于insert_pfn创建将页框插入用户空间页表的映射。我并不完全确定，但似乎由于页框直接插入用户空间页表，因此从用户空间访问这些页面不需要内核级取消引用，因此不会触发 MTE。
|
||||
|
||||
结论
|
||||
|
||||
在本文中，我展示了如何利用 CVE-2025-0072 在启用内核 MTE 的 Pixel 8 上实现任意内核代码执行。与我之前报告的漏洞（通过访问 GPU 释放的内存来绕过 MTE）不同，此漏洞通过驱动程序插入的用户空间内存映射来访问释放的内存。这表明，当通过用户空间的内存映射访问释放的内存页面时，MTE 也可以被绕过，这种情况比之前的漏洞更为常见。
|
||||
|
||||
|
||||
|
||||
|
||||
感谢您抽出
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
来阅读本文
|
||||
|
||||
|
||||
|
||||
**点它，分享点赞在看都在这里**
|
||||
|
||||
@@ -0,0 +1,130 @@
|
||||
# 速修！Kafka Connect爆任意文件读取漏洞，无需授权
|
||||
原创 微步情报局 微步在线研究响应中心 2025-06-10 02:20
|
||||
|
||||
|
||||
|
||||
|
||||
**漏洞概况**
|
||||
|
||||
|
||||
|
||||
Apache Kafka Connect是Apache Kafka生态系统中的一个组件，它提供了一种可靠且可扩展的方式来连接Kafka与其他系统。
|
||||
|
||||
微步情报局通过X漏洞奖励计划获取到Apache Kafka Connect任意文件读取漏洞（https://x.threatbook.com/v5/vul/XVE-2024-28168），攻击者可在未授权的情况下，通过该漏洞读取系统敏感文件，利用难度较低。另外，由于Apache Druid 使用了受影响的Kafka版本，也受该漏洞影响。Kafka官方已修复该漏洞，建议受影响的客户尽快修复。
|
||||
|
||||
|
||||
|
||||
|
||||
**漏洞处置优先级(VPT)**
|
||||
|
||||
|
||||
|
||||
**综合处置优先级：高**
|
||||
<table><tbody><tr style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;height: 31.0667px;visibility: visible;"><td rowspan="5" data-colwidth="110" width="110" style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px 7.2px;outline: 0px;overflow-wrap: break-word !important;word-break: break-all;hyphens: auto;border: 0.666667px solid rgb(191, 191, 191);max-width: 100%;box-sizing: border-box !important;vertical-align: top;visibility: visible;"><p style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;clear: both;min-height: 1em;visibility: visible;"><span style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;color: rgb(84, 84, 84);font-size: 14px;letter-spacing: 1px;visibility: visible;"><strong style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;"><span leaf="">基本信息</span></strong></span><o:p style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;"></o:p></p></td><td data-colwidth="188" width="158.33333333333334" style="padding: 0px 7.2px;outline: 0px;word-break: break-all;hyphens: auto;border-width: 0.666667px;border-color: rgb(191, 191, 191);vertical-align: top;"><p style="outline: 0px;"><span style="outline: 0px;color: rgb(84, 84, 84);letter-spacing: 1px;font-size: 14px;"><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);font-weight: normal;">微步编号</span></span></span><o:p style="outline: 0px;"></o:p></p></td><td data-colwidth="229" width="88" style="padding: 0px 7.2px;outline: 0px;word-break: break-all;hyphens: auto;border-width: 0.666667px;border-color: rgb(191, 191, 191);vertical-align: top;"><span style="font-size: 14px;color: rgb(84, 84, 84);" data-pm-slice="2 2 ["table",{"interlaced":null,"align":null,"class":null,"style":"width:557px;"},"table_body",null,"table_row",{"class":null,"style":"outline: 0px;height: 31.0667px;"},"table_cell",{"colspan":1,"rowspan":1,"colwidth":[261],"width":"88","valign":null,"align":null,"style":"padding: 0px 7.2px;outline: 0px;word-break: break-all;hyphens: auto;border-width: 0.666667px;border-color: rgb(191, 191, 191);vertical-align: top;"},"para",{"tagName":"p","attributes":{},"namespaceURI":"http://www.w3.org/1999/xhtml"}]"><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);font-weight: normal;">XVE-</span></span><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);font-weight: normal;">2024-</span></span><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);font-weight: normal;">28168</span></span></span></td></tr><tr><td data-colwidth="188"><section><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);font-weight: normal;">CVE编号</span></span></section></td><td data-colwidth="229"><section><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);font-weight: normal;">C</span></span><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);font-weight: normal;">VE-2025-27817</span></span></section></td></tr><tr><td data-colwidth="188"><section><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);">C</span></span><span style="color: rgb(84, 84, 84);font-size: 14px;letter-spacing: 0.544px;"><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);">NNVD编号</span></span></span></section></td><td data-colwidth="229"><p><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);">CNNVD-2024-30029666</span></span></p></td></tr><tr><td data-colwidth="188"><p data-pm-slice="0 0 []"><span style="mso-spacerun:'yes';font-family:微软雅黑;font-size:10.5000pt;mso-font-kerning:0.0000pt;"><font face="微软雅黑"><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);">NVDB编号</span></span></font></span></p></td><td data-colwidth="229"><p data-pm-slice="0 0 []"><span style="mso-spacerun:'yes';font-family:微软雅黑;font-size:10.5000pt;"><font face="微软雅黑"><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);">NVDB-CNVDB-2024409929</span></span></font></span></p></td></tr><tr style="-webkitLine truncated
|
||||
****
|
||||
**漏洞影响范围**
|
||||
|
||||
|
||||
|
||||
<table><tbody><tr style="outline: 0px;height: 33.2px;"><td data-colwidth="148" width="152" style="padding: 0px 7.2px;outline: 0px;word-break: break-all;hyphens: auto;border-width: 0.666667px;border-color: rgb(191, 191, 191);vertical-align: top;"><p style="outline: 0px;"><strong style="outline: 0px;"><span style="outline: 0px;color: rgb(84, 84, 84);letter-spacing: 1px;font-size: 14px;"><span leaf="">产品名称</span></span></strong><o:p style="outline: 0px;"></o:p></p></td><td data-colwidth="398" width="346" style="padding: 0px 7.2px;outline: 0px;word-break: break-all;hyphens: auto;border-width: 0.666667px;border-color: rgb(191, 191, 191);vertical-align: top;"><p><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);">Apache软件基金会 | Apache Kafka</span></span></p></td></tr><tr style="outline: 0px;height: 27px;"><td data-colwidth="148" width="172" style="padding: 0px 7.2px;outline: 0px;word-break: break-all;hyphens: auto;border-width: 0.666667px;border-color: rgb(191, 191, 191);vertical-align: top;"><p style="outline: 0px;"><strong style="outline: 0px;"><span style="outline: 0px;color: rgb(84, 84, 84);letter-spacing: 1px;font-size: 14px;"><span leaf="">受影响版本</span></span></strong><o:p style="outline: 0px;"></o:p></p></td><td data-colwidth="398" width="346" style="padding: 0px 7.2px;outline: 0px;word-break: break-all;hyphens: auto;border-width: 0.666667px;border-color: rgb(191, 191, 191);vertical-align: top;"><p><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);">3.1.0 ≤ version < 3.9.1</span></span></p></td></tr><tr style="outline: 0px;height: 27px;"><td data-colwidth="148" width="172" style="padding: 0px 7.2px;outline: 0px;word-break: break-all;hyphens: auto;border-width: 0.666667px;border-color: rgb(191, 191, 191);vertical-align: top;"><p data-pm-slice="0 0 []"><span style=""><font face="微软雅黑"><span leaf=""><span textstyle="" style="font-size: 14px;color: rgb(84, 84, 84);font-weight: bold;">有无修复补丁</span></span></font></span><o:p style="outline: 0px;"></o:p></p></td><td data-colwidth="398" width="346" style="padding: 0px 7.2px;outline: 0px;word-break: break-all;hyphens: auto;border-width: 0.666667px;border-color: rgb(191, 191, 191);vertical-align: top;"><span style="letter-spacing: 0.578px;font-size: 14px;color: rgb(84, 84, 84);"><span leaf="">有</span></span></td></tr></tbody></table>
|
||||
|
||||
**漏洞复现**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**修复方案**
|
||||
|
||||
|
||||
|
||||
|
||||
**官方修复方案：**
|
||||
|
||||
Kafka官方已发布修复版本，请尽快更新至3.9.1及以上版本：
|
||||
- 通告链接：https://lists.apache.org/thread/6cm2d0q5126lp7w591wt19211s5xxcsm
|
||||
|
||||
- 下载链接：https://github.com/apache/kafka/releases/tag/3.9.1
|
||||
|
||||
## 临时缓解措施：
|
||||
|
||||
1. 避免将Kafka Connect实例对外网开放，配置方式如下：
|
||||
- 若使用standalone模式启动Kafka Connect，则可通过修改connect-standalone.properties配置文件中的listeners或rest.host.name字段进行配置；
|
||||
|
||||
- 若使用distributed模式启动Kafka Connect，则可通过修改connect-distributed.properties配置文件中的listeners或rest.host.name字段进行配置。
|
||||
|
||||
2. 使用流量防护设备，对/connectors的
|
||||
请求体中含有敏感文件路径的访问请求
|
||||
进行拦截。
|
||||
|
||||
|
||||
**微步产品侧支持情况**
|
||||
|
||||
|
||||
|
||||
微步
|
||||
威胁感知平台TDP
|
||||
已支持检测，
|
||||
TDP检测ID：
|
||||
S3100154573、S3100154580
|
||||
，模型/规则高于
|
||||
|
||||
20241009000000 可检出。
|
||||
|
||||
|
||||
|
||||
微步威胁防御系统OneSIG已支持防护，规则ID为：3100150726。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- END -
|
||||
|
||||
|
||||
//
|
||||
|
||||
**微步漏洞情报订阅服务**
|
||||
|
||||
|
||||
微步提供漏洞情报订阅服务，精准、高效助力企业漏洞运营：
|
||||
- 提供高价值漏洞情报，具备及时、准确、全面和可操作性，帮助企业高效应对漏洞应急与日常运营难题；
|
||||
|
||||
- 可实现对高威胁漏洞提前掌握，以最快的效率解决信息差问题，缩短漏洞运营MTTR；
|
||||
|
||||
- 提供漏洞完整的技术细节，更贴近用户漏洞处置的落地；
|
||||
|
||||
- 将漏洞与威胁事件库、APT组织和黑产团伙攻击大数据、网络空间测绘等结合，对漏洞的实际风险进行持续动态更新
|
||||
。
|
||||
|
||||
|
||||
扫码在线沟通
|
||||
|
||||
↓
|
||||
↓↓
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[点此电话咨询]()
|
||||
|
||||
|
||||
|
||||
|
||||
**X漏洞奖励计划**
|
||||
|
||||
|
||||
“X漏洞奖励计划”是微步X情报社区推出的一款
|
||||
针对未公开
|
||||
漏洞的奖励计划，我们鼓励白帽子提交挖掘到的0day漏洞，并给予白帽子可观的奖励。我们期望通过该计划与白帽子共同努力，提升0day防御能力，守护数字世界安全。
|
||||
|
||||
活动详情：
|
||||
https://x.threatbook.com/v5/vulReward
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user