前几天有消息说 在 C 标准库 uClibc 和 uClibc-ng 中，用于许多嵌入式和便携式设备， 已发现漏洞 （尚未分配 CVE），它允许替换 DNS 缓存中的虚拟数据，这可用于欺骗缓存中任意域的 IP 地址，并将对该域的请求重定向到攻击者的服务器。
关于这个问题，有人提到这个 影响路由器、接入点和物联网设备的各种 Linux 固件， 以及嵌入式 Linux 发行版，如 OpenWRT 和 Embedded Gentoo。
关于漏洞
脆弱性 是由于在代码中使用了可预测的事务标识符来发送查询 的 DNS。 DNS 查询 ID 是通过简单地增加计数器而不进一步随机化端口号来选择的，这 使毒害 DNS 缓存成为可能 通过抢先发送带有虚假响应的 UDP 数据包（如果响应在真实服务器的响应之前到达并且包含正确的标识，则响应将被接受）。
与 2008 年提出的 Kaminsky 方法不同，它甚至不需要猜测事务 ID，因为它最初是可预测的（最初，它被设置为 1，随着每个请求而增加，并且不是随机选择的）。
为了保护自己 反对ID猜测，规范 进一步推荐使用随机分布的网络端口号 发送 DNS 查询的来源，以弥补 ID 大小的不足。
启用端口随机化时，要形成一个虚拟响应，除了选择一个 16 位的标识符外，还需要选择网络端口号。 在 uClibc 和 uClibc-ng 中，没有显式启用这种随机化（调用 bind 时，没有指定随机源 UDP 端口），其实现取决于操作系统配置。
当端口随机化被禁用时， 确定要增加的请求 id 被标记为琐碎任务. 但即使在随机化的情况下，攻击者也只需要在 32768-60999 范围内猜测网络端口即可，为此他可以在不同的网络端口上大量同时发送虚拟响应。
问题 已在所有当前版本的 uClibc 和 uClibc-ng 中得到确认，包括最新版本的 uClibc 0.9.33.2 和 uClibc-ng 1.0.40。
“重要的是要注意，影响标准 C 库的漏洞可能非常复杂，”该团队本周在一篇博客文章中写道。
“不仅在单个程序中的多个点对易受攻击的函数进行数百或数千次调用，而且该漏洞会影响配置为使用该库的无限数量的其他多供应商程序。”
2021 年 XNUMX 月，发送了有关漏洞的信息 到 CERT/CC 进行协调的阵列准备。 2022年XNUMX月， 该问题已与 200 多家制造商共享 与 CERT/CC 相关联。
XNUMX 月份曾尝试单独联系 uClibc-ng 项目的维护者，但他回复称自己无法修复该漏洞，并建议公开披露该问题的信息，希望得到开发修复的帮助。社区。 来自制造商的 NETGEAR 宣布发布更新以消除漏洞。
需要注意的是，影响标准 C 库的漏洞可能非常复杂。 不仅会在单个程序的多个点对易受攻击的函数进行数百或数千次调用，而且该漏洞还会影响来自多个供应商的无限数量的其他程序，这些程序配置为使用该库。
值得注意的是，该漏洞存在于许多制造商的设备中（例如，uClibc 用于 Linksys、Netgear 和 Axis 的固件中），但由于该漏洞在 uClibc 和 uClibc-ng 中仍未修补，因此有关设备的详细信息和特定制造商的产品存在问题，直到他们被披露。
最后 如果您有兴趣了解更多有关它的信息，您可以查看详细信息 在下面的链接中。