如截图所示，base64_decode()函数没有考虑长度因素。
已添加了一个if语句来检查base64编码字符串长度是否小于0x556（1366）字节。如果这个检查通过，字符串会被解码进1024字节的堆栈缓冲区。
受影响的函数与动态负载均衡（DLB）协议相关，该协议在电动汽车充电器网络之间分配电力负载。在充电器之间的初始通信过程中，每个充电器都会在JSON RPC负载中接收到一个共享的AES-128密钥。该密钥被编码为十六进制字符串，并作为参数传递给被调用的RPC函数。
被调用的函数提取JSON RPC参数中的十六进制编码密钥，然后将其解码到一个固定大小的栈缓冲区。该栈缓冲区为16字节，但由于对齐原因，在栈上占用了20字节。这对于AES-128密钥来说是正确的大小，然而，由于攻击者可以提供一个更长的字符串，因此可能会发生缓冲区溢出。
与前面提到的base64_decode()问题不同，hex_decode()函数确实接受一个长度参数（即编码后的密钥长度），但这并不能防止溢出，因为从未将该长度与缓冲区的大小进行比较。
原文始发于微信公众号（安全脉脉）：Autel MaxiCharger（CVE-2024-23967 /CVE-2024-23957解析）
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论