思科安全研究人员 细节 (）在 Glibc 为 32 位 ARMv7 平台提供的 memcpy() 函数的实现中。 该问题是由于使用操作有符号 32 位整数的汇编优化而导致对确定复制区域大小的参数负值的错误处理造成的。 在 ARMv7 系统上调用具有负大小的 memcpy() 会导致值比较不正确并写入指定缓冲区边界之外的区域。
在攻击者可以组织传输复制数据大小的变量为负值的情况下，可以利用该漏洞执行代码（例如，传输超过 2 GB 的数据时，该变量将变为负值）。数据，但在攻击期间，要超出缓冲区限制，您需要传输至少 4GB）。 memcpy() 函数在应用中广泛使用，ARMv7 处理器常见于汽车系统、移动、工业、消费、通信和嵌入式设备，这些设备可能会受到使用蓝牙、HD Radio/DAB、USB、CAN 总线的攻击， Wi-Fi Fi 和其他外部数据源（例如，通过网络访问且接受无大小限制的输入数据的服务和应用程序可能会受到攻击）。
一个例子是创建一个有效的漏洞来攻击内置于汽车信息系统中的 HTTP 服务器，可通过汽车 Wi-Fi 网络访问。 外部攻击者可以通过发送非常大的 GET 请求来利用该服务器上的 memcpy 漏洞并获得系统的 root 访问权限。
在 32 位 x86 系统上，不会出现该问题，因为该架构的 memcpy 实现正确地将 size 变量解释为 size_t 类型的无符号整数值（用汇编语言表示） 对于 ARMv7，它被视为有符号整数而不是 size_t）。 该修复目前可用 ，它将包含在 2.32 月份的 Glibc XNUMX 更新中。
该修复归结为将对有符号操作数（bge 和 blt）进行操作的汇编指令替换为无符号对应操作数（blo 和 bhs）。
问题还没有解决 （在 Debian 8 中不可见）， , 、OpenEmbedded、Tizen（由 glibc 使用）。 и 该问题不受影响，因为它们不支持 32 位 ARMv7 系统。 Android 不受该漏洞影响，因为它使用自己的 libc (Bionic) 实现。 在 默认情况下，大多数构建都使用 Musl，但存储库中也提供了 glibc。
来源： opennet.ru