ESP-IDF: Stack-based memory corruption in lwIP DNS/SNTP handling for multi-IP DNS responses

Summary

ESP-IDF is the Espressif Internet of Things (IOT) Development Framework. From 5.2.3 until 5.3.7, 5.4.5, 5.5.6, and 6.0.3, the lwIP DNS resolver's cached-lookup path in dns_lookup() in dns.c copies every cached address into a caller-provided single ip_addr_t output buffer without a length parameter or bounds check. When CONFIG_LWIP_DNS_MAX_HOST_IP is greater than 1 and a cached hostname has multiple A or AAAA records, a subsequent lookup through dns_gethostbyname() or dns_gethostbyname_addrtype() writes beyond the single-element buffer into adjacent stack memory. A network-positioned attacker who influences DNS responses can cause a reboot through stack-canary corruption or, without stack protection, overwrite stack variables with attacker-controlled address bytes and potentially redirect control flow. This issue is fixed in versions 5.5.6 and 6.0.3 and is scheduled to be fixed in versions 5.3.7 and 5.4.5. No fixed release is available for the end-of-life 5.2 line.

Remediation

1. Inventory every espressif esp-idf deployment, including staging.
2. No fixed version appears in the public sources yet. Check the references below and the vendor directly.

References

• Referencehttps://github.com/espressif/esp-idf/commit/75f2ff7e0c2d19e113293ec122b701c83d2f6665
• Referencehttps://github.com/espressif/esp-idf/commit/7ab85eb4dc7d7695960d940badcd62592c365056
• Referencehttps://github.com/espressif/esp-idf/commit/882843dbf838b0c02e09d46bb6283bda73496b8c
• Referencehttps://github.com/espressif/esp-idf/commit/98e6e7a08fca391563651a1e751cc45a3b27d18b
• Referencehttps://github.com/espressif/esp-idf/commit/af7543d00a4d7b489e010a70b59fd3d8022a40f4
• Referencehttps://github.com/espressif/esp-idf/commit/defaa2f559470acfee5e2e5ea80a79b73424d483
• Referencehttps://github.com/espressif/esp-idf/security/advisories/GHSA-ch63-jxm5-vmvf