1. 项目概述从CVE编号到真实威胁的映射看到CVE-2025-61618这个编号很多做移动通信安全或者终端设备固件分析的朋友可能会心头一紧。NR也就是New Radio5G网络的空中接口标准而调制解调器Modem则是手机、物联网设备连接5G网络的核心通信芯片。一个在NR调制解调器上被曝光的远程拒绝服务漏洞意味着攻击者可能不需要接触你的设备只要你的设备连着网就能让它“罢工”。这听起来有点吓人但更吓人的是很多公开的分析往往停留在CVSS评分7.5、攻击向量是网络这类表面信息上对于漏洞到底怎么触发、在代码的哪个环节出了问题、实际影响范围有多大却语焉不详。我花了些时间结合对蜂窝网络协议栈和嵌入式系统安全的理解来深挖一下这个漏洞。它被标记为“输入验证不当”这五个字在安全报告里太常见了常见到几乎失去了信息量。但在NR调制解调器的上下文里这个“输入”特指什么是来自基站的无线信号RRC消息还是来自设备上层应用的数据包验证“不当”又具体指哪种不当是长度检查缺失、范围校验错误还是对异常状态的处理逻辑有缺陷搞清这些你才能判断这个漏洞是实验室里的理论风险还是能写出稳定攻击代码的真实威胁。另外热词里提到的“nr drb的建立”非常关键这指向了5G中数据无线承载Data Radio Bearer的建立过程这通常是协议栈中状态复杂、容易出错的环节很可能就是漏洞的藏身之处。这篇文章我会从一个实战分析者的角度带你还原CVE-2025-61618。我们不止看公开的描述更要结合5G NR协议栈的实现特点、嵌入式实时操作系统RTOS的常见缺陷模式以及模糊测试Fuzzing在挖掘这类漏洞时的思路把“输入验证不当”这个模糊的概念还原成具体的代码逻辑缺陷和可复现的崩溃场景。无论你是从事物联网安全研究、移动终端测试还是对底层系统安全感兴趣相信都能从中看到一些门道。2. 漏洞核心原理与NR协议栈背景剖析2.1 NR调制解调器的软件架构与风险面要理解这个漏洞首先得知道NR调制解调器软件大概是怎么工作的。它不是一个简单的驱动程序而是一个复杂的、实时性要求极高的嵌入式软件系统通常运行在专用的基带处理器上。其核心是协议栈软件遵循3GPP标准层层实现从物理层PHY到无线资源控制层RRC的功能。一个简化的分层视图如下L1物理层处理最底层的编码、调制、信号处理。这部分的代码很多是高度优化的汇编或专用DSP代码漏洞多与内存操作溢出相关。L2数据链路层包括MAC媒体接入控制、RLC无线链路控制、PDCP分组数据汇聚协议。负责调度、重传、加密和完整性保护。这一层要处理大量的数据包和状态机是逻辑漏洞的高发区。L3网络层核心就是RRC层。它负责连接管理、移动性管理、承载建立/修改/释放等。RRC层是调制解调器与网络基站进行“对话”的指挥官也是接收并解析所有来自网络的“命令”RRC消息的地方。这里就是“输入验证”的主战场。所有的“输入”最终都来源于基站通过空口发送的、符合3GPP 38.331规范定义的RRC消息。调制解调器的协议栈需要解析这些ASN.1编码的二进制消息将其转化为内部数据结构并驱动相应的状态转换和资源配置。注意这里存在一个关键的安全假设偏差。协议栈开发者的潜意识里往往默认基站是“善意的”发送的消息是符合规范的。因此代码中对消息内容的校验可能不够充分或者只考虑了“合法但错误”的情况而没考虑“故意畸形、旨在破坏”的情况。CVE-2025-61618的根源很可能就在这里。2.2 “输入验证不当”在NR上下文中的具体含义在公开描述中“输入验证不当”导致系统崩溃。在NR调制解调器的RRC层输入验证通常包括以下几个维度任何一个维度的缺失或错误都可能导致崩溃消息结构完整性验证ASN.1 PER压缩编码或Unaligned PER解码后检查必选字段是否存在可选字段标记是否合理。例如一条携带“nr drb的建立”相关配置的RRCReconfiguration消息其中必须包含radioBearerConfig字段。如果攻击者伪造的消息中该字段缺失或标记为“不存在”但后续代码逻辑又强制去访问它就会导致空指针解引用。字段值域边界验证检查字段值是否在协议规定的有效范围内。例如DRB-Identity数据无线承载标识的值范围是1~32。如果攻击者将其设置为0或33而协议栈代码使用这个值作为数组索引如drb_context[identity]且没有进行边界检查就会导致数组越界访问可能读/写到非法内存。逻辑一致性验证检查不同字段之间的逻辑关系是否合理。例如在配置一个DRB时会同时配置其对应的PDCP-Config、RLC-Config和LogicalChannelConfig。如果RLC-Config中指定了“确认模式AM”但LogicalChannelConfig中却配置了一个不允许重传的优先级这种组合在协议上可能是无效的。如果协议栈代码没有检查这种跨字段的一致性在后续处理时进入未预期的代码路径就可能引发断言失败或资源分配错误。状态机上下文验证检查收到的消息是否与当前协议栈的状态匹配。例如在RRC_IDLE状态下突然收到一条要求修改DRB的RRCReconfiguration消息这显然是不合法的。代码需要拒绝此消息。如果状态检查被绕过可能导致协议栈状态混乱。结合“nr drb的建立”这个热词我高度怀疑漏洞触发点与RRCReconfiguration消息处理流程强相关。这条消息用于建立、修改或释放DRB。建立DRB是一个多步骤的复杂过程涉及L2各子层PDCP、RLC、MAC实体创建、资源配置、与网络侧参数协商等。在这个过程中如果攻击者伪造的RRCReconfiguration消息包含一个无效的、或自相矛盾的DRB-ToAddMod列表而协议栈在解析并尝试应用这些配置时某一步的验证缺失就可能在分配内存、初始化数据结构、配置硬件寄存器时发生致命错误导致内核崩溃如看门狗超时、非法内存访问。2.3 漏洞利用场景与影响分析这个漏洞被标记为“远程利用是”且攻击向量是“网络”所需权限和用户交互都是“无”。这意味着攻击者位置理论上攻击者可以伪装成一个恶意的基站伪基站。在5G NSA组网下甚至可能通过控制核心网侧的某些网元向目标用户发送恶意的RRC信令。攻击条件目标设备需要处于蜂窝网络覆盖下不一定是5G也可能是4G锚点并且与网络建立了RRC连接。设备不需要安装任何恶意软件用户也无需进行任何点击操作。攻击效果导致调制解调器固件崩溃。最直接的表现就是设备“脱网”——信号栏显示无服务无法拨打/接听电话无法使用移动数据。根据调制解调器与主处理器AP的耦合程度以及复位机制可能导致调制解调器子系统重启相对温和几秒到几十秒后恢复服务。整个设备重启如果调制解调器崩溃触发了整个系统的看门狗复位用户体验就是手机突然黑屏重启。永久性拒绝服务如果崩溃破坏了关键的非易失性配置数据如NV项可能导致调制解调器无法正常初始化需要返厂维修。影响范围虽然公开的受影响产品列表为空常见于漏洞刚被分配CVE时但可以推断使用特定厂商如Unisoc展锐漏洞来源方基带芯片或协议栈软件的设备都可能受影响。这包括大量中低端智能手机、物联网模块如Cat.1, Cat.4模组、车载T-Box等。由于基带固件更新通常滞后且依赖厂商推送漏洞的潜在影响周期会很长。3. 漏洞深度挖掘与逆向分析思路3.1 基于模糊测试Fuzzing的漏洞发现路径像CVE-2025-61618这类输入验证漏洞在现代安全研究中很大概率是通过模糊测试发现的。对于NR协议栈一个高效的Fuzzing策略如下目标选择不直接Fuzz整个调制解调器固件太难。而是Fuzz运行在应用处理器AP上的“协议栈适配层”或“测试接口”如Diag端口、AT命令端口。很多厂商会有用于内部测试的RRC消息注入工具。语料库生成以3GPP 38.331规范为基础收集合法的RRC消息流通过空口抓取或从测试用例中提取。使用asn1c编译器将规范生成编解码代码以此为基础构建Fuzzer。变异策略结构变异随机删除、添加、重复消息中的字段或IE信息元素。值域变异对整型、枚举值进行极值0, -1, MAX1或随机值替换。逻辑变异故意制造字段间的矛盾比如在配置DRB时设置一个超大的logicalChannelGroup值或者将rlc-Config设置为空。监控与反馈Fuzzer需要监控目标进程的异常如崩溃SIGSEGV, SIGABRT、断言失败、内存泄漏、以及协议栈状态异常如状态机卡死。覆盖率引导Coverage-guided的Fuzzer如AFL libFuzzer能有效探索新的代码路径。实操心得对嵌入式协议栈Fuzzing最大的挑战是执行速度和环境依赖。直接运行在实机或仿真器上太慢。一个可行的办法是将协议栈的关键消息处理函数如rrc_reconfiguration_decode_and_process剥离出来编译成一个运行在Linux用户空间的库然后针对这个库进行内存Fuzzing。这需要一定的逆向工程和代码移植工作但一旦成功Fuzzing效率将大大提升。3.2 静态代码分析与可疑代码模式定位如果没有Fuzzing环境通过静态分析寻找此类漏洞也有迹可循。假设我们能获得疑似受影响版本的协议栈二进制文件哪怕是某个IoT模组的固件提取物可以尝试以下步骤符号恢复与字符串搜索在二进制中搜索关键字符串如“DRB-ToAddMod”、“RRCReconfiguration”、“reconfigurationWithSync”等。这些往往是编解码或日志打印函数中的标志能帮我们快速定位到关键函数。关注ASN.1解码回调函数协议栈使用ASN.1编译器生成的代码进行解码。解码器会对每个字段调用一个asn1c_xxx_decoder函数最终调用到协议栈自己实现的xxx_ies_decoder。漏洞往往就藏在xxx_ies_decoder或其调用的验证函数里。我们需要反汇编这些函数查看在字段赋值给内部结构体struct drb_config_t之前是否有明显的边界检查指令如CMPBHI/BLS。是否有对指针解引用前的判空检查LDR指令前是否有CBZ或CMP。寻找“危险”的数组或链表操作在DRB配置处理函数中极有可能存在一个以DRB-Identity为索引的全局数组或链表用于管理所有DRB的上下文。反汇编代码中寻找类似ldr r1, [r0, r3, lsl #2]数组访问或遍历链表的循环。检查索引值r3是否在访问前与数组大小如32进行了比较。分析崩溃上下文如果能有崩溃现场的日志或内存转储如ramdump价值巨大。查看崩溃时的程序计数器PC和调用栈看它死在哪个函数里。如果死在memcpy、memset或某个内存分配函数里结合当时的参数基本就能断定是缓冲区溢出。如果死在访问0x00000000或0xdeadbeef这样的地址那就是空指针或野指针。一个假设的漏洞代码模式示例伪代码// 假设这是处理 DRB-ToAddMod 列表的函数存在漏洞 void process_drb_add_mod_list(asn1c_drb_to_add_mod_list_t *asn1_list) { drb_config_t *drb_context get_global_drb_context_array(); // 全局数组大小32 for (int i 0; i asn1_list-count; i) { asn1c_drb_to_add_mod_t *asn1_drb asn1_list-items[i]; int drb_id asn1_drb-drb_Identity; // [漏洞点] 未验证 drb_id 是否在1~32范围内 // 直接使用 drb_id 作为索引如果 drb_id0 或 33则越界 drb_config_t *config drb_context[drb_id]; config-pdcp_config decode_pdcp_config(asn1_drb-pdcp_Config); config-rlc_config decode_rlc_config(asn1_drb-rlc_Config); // ... 其他配置 if (asn1_drb-cellGroupId) { // 这是一个可选字段 // [另一个可能的漏洞点] 如果 cellGroupId 指向一个非常大的值可能导致后续计算溢出 config-cell_group *asn1_drb-cellGroupId; } } }上面这段伪代码展示了两个典型的漏洞模式数组索引越界和可选字段未校验即使用。攻击者通过精心构造一个包含drb_Identity 0或33的RRCReconfiguration消息即可触发崩溃。4. 漏洞复现与调试环境搭建构想4.1 模拟复现环境的搭建思路完全在真实网络和真实设备上复现此类漏洞成本高、风险大且难以调试。一个更可行的思路是搭建一个软件模拟的测试环境目标协议栈获取理想情况获得目标调制解调器芯片的SDK或协议栈库文件.a或.so。这通常来自设备固件提取或通过某些渠道获得。替代方案使用开源实现进行原理性复现。例如研究OAIOpenAirInterface的5G UE协议栈实现。虽然与商业实现差异大但其代码结构、消息处理流程是相似的可以用来理解漏洞模式并构建攻击样本。测试框架构建编写一个简单的测试程序链接协议栈库。实现一个模拟的“RRC消息注入器”能够构造并发送二进制格式的RRC消息如RRCReconfiguration到协议栈的入口函数。协议栈运行在一个独立的线程或进程中通过IPC接收消息。崩溃监控与调试使用gdb附加到测试进程设置catchpoint来捕捉SIGSEGV、SIGABRT等信号。使用AddressSanitizer (ASAN)或UndefinedBehaviorSanitizer (UBSAN)编译测试程序和协议栈库如果可能。这能极大帮助发现内存错误。记录完整的函数调用栈、寄存器状态以及触发崩溃的原始消息数据。4.2 构造PoC概念验证攻击消息基于前面的分析我们可以尝试构造一个能触发崩溃的恶意RRCReconfiguration消息。这里以ASN.1 PER编码为例描述其结构消息头设置messageType c1 - rrcReconfiguration。关键攻击载荷 -radioBearerConfig确保该字段存在。在drb-ToAddModList中放置一个或多个DRB-ToAddMod元素。针对第一个漏洞模式数组越界设置drb-Identity 0。根据规范有效值是1-320是无效值。针对第二个漏洞模式逻辑矛盾同时设置pdcp-Config为discardTimer ms100一个合法值但将rlc-Config设置为ul-AM-RLC却把sn-FieldLength设为size2对于AM模式通常需要size12或size18制造一个协议栈可能未处理的矛盾配置。更复杂的组合设置drb-Identity 32边界值然后在其rlc-Config中嵌套一个深度异常或长度异常的子结构考验解析器的递归深度或栈空间。编码与发送使用asn1c生成的编码函数将上述结构体编码成二进制串。通过测试框架的注入接口将该二进制串发送给协议栈。注意事项商业协议栈通常有很强的鲁棒性简单的无效值可能只会导致消息被静默丢弃并记录错误日志。要触发崩溃可能需要找到多个验证缺失点的组合或者利用验证逻辑本身的缺陷比如先校验了范围但在后续的某个分支又使用了未经验证的原始值。这需要反复试验和动态调试。5. 缓解措施、修复方案与深度防御5.1 厂商层面的修复与补丁分析根据漏洞描述解决方案是“解决输入验证不当的问题”。对于厂商而言这意味着需要在协议栈代码中增加严格的校验。修复可能涉及以下文件以假设的代码结构为例src/rrc/rrc_reconfiguration_decoder.c在解码函数中对drb_Identity增加范围检查并立即拒绝无效消息。src/rrc/rrc_config_validator.c增加一个专门的配置验证模块在应用任何配置之前检查跨字段的逻辑一致性例如DRB配置与UE能力是否匹配各层配置之间是否兼容。src/pdcp/pdcp_entity_management.c和src/rlc/rlc_entity_management.c在根据配置创建实体时增加对配置参数的运行时断言assert在调试版本中及早发现问题。一个健壮的修复不仅仅是打补丁更应建立长效机制代码审计对所有来自外部的消息处理函数进行人工或自动化审计确保每个输入点都有验证。模糊测试常态化将针对RRC层的Fuzzing集成到CI/CD流水线中持续发现潜在问题。防御性编程使用安全的内存操作函数如memcpy_s启用栈保护-fstack-protector将关键数据结构隔离到受保护的内存区域。5.2 设备用户与企业的应对策略对于使用可能受影响设备的个人用户和企业来说等待厂商推送固件更新是主要手段但也可以采取一些缓解措施更新固件密切关注设备制造商或芯片提供商如Unisoc的安全公告及时应用基带固件更新。对于物联网设备这可能需要通过OTA或返厂进行。网络层防护在企业环境中可以通过移动安全网关或具有信令过滤功能的防火墙尝试检测和拦截异常的RRC信令流量。但这需要深厚的协议分析能力且可能影响正常业务。物理与网络隔离对重要的物联网设备将其部署在受控的物理环境和专网中减少暴露在公共蜂窝网络下的攻击面。监控与响应建立设备异常行为监控如频繁的调制解调器复位、异常的网络掉线。这些可能是正在遭受攻击的迹象。5.3 对安全研究人员的启示CVE-2025-61618再次凸显了嵌入式系统和通信协议安全的重要性。这类漏洞往往深藏在专有、闭源的固件中挖掘门槛高但一旦利用影响广泛且难以防御。研究方向除了传统的二进制漏洞挖掘可以更多关注协议状态机安全。思考如何通过发送一系列合法的消息将协议栈引导至一个非预期的、脆弱的中间状态再发送恶意消息触发漏洞。这种“逻辑漏洞”往往能绕过简单的输入校验。工具链熟练掌握针对ARM Cortex-R/M系列常用于基带处理器的逆向分析工具如IDA Pro, Ghidra和调试手段如JTAG。学习使用asn1c和相关的Fuzzing框架如boofuzz针对协议Fuzzing构建针对性的测试工具。协作与蜂窝网络领域的工程师交流理解协议的实际实现细节和常见的“技术债”区域这能极大提升漏洞挖掘的效率和精准度。这个漏洞的分析过程本质上是一次对复杂系统“信任边界”的审视。在万物互联的时代那些默认为可信的通信链路和协议实现正在成为攻击者眼中新的、富有吸引力的攻击面。