A vulnerability has been identified in the standard C libraries uClibc and uClibc-ng, used in many embedded and portable devices, that allows for the injection of fake data into the DNS cache. This can be exploited to substitute the cached IP address of any domain and redirect requests for that domain to an attacker’s server.
The issue affects various Linux firmware for routers, access points, and Internet of Things devices, as well as Linux distributions for embedded systems, such as OpenWRT and Embedded Gentoo. It has been noted that the vulnerability manifests in devices from many manufacturers (for example, uClibc is used in firmware for Linksys, Netgear, and Axis), but as the vulnerability in uClibc and uClibc-ng remains unpatched, detailed information about specific devices and manufacturers affected by the issue is not yet disclosed.
The vulnerability is caused by the use of predictable transaction identifiers in the code for sending DNS queries. The DNS request ID is chosen by simply incrementing a counter without any additional port number randomization, which allows for DNS cache poisoning through preemptive sending of UDP packets containing fake responses (the response will be accepted if it arrives before the real answer and includes the correct ID). server In contrast to the method proposed by Kaminsky in 2008, the transaction identifier does not even need to be guessed, as it is inherently predictable (initially set to 1, it increments with each request rather than being randomly selected).
The specification for protection against identifier guessing recommends additionally employing randomization of source network port numbers from which DNS requests are sent, which compensates for the insufficiently large identifier size. When enabling port randomization for generating fake responses, it is necessary to guess not only the 16-bit identifier but also the network port number. In uClibc and uClibc-ng, such randomization was not explicitly included (as a random source UDP port was not specified when calling bind), and its application depended on the operating system's settings.
When randomization of sockets is disabled, determining the incremental request identifier is marked as a trivial task. However, even when randomization is applied, the attacker only needs to guess the network port from the range of 32768–60999, for which they can use massive simultaneous sending of spoofed responses across different network ports.
The issue has been confirmed in all current releases of uClibc and uClibc-ng, including the latest versions uClibc 0.9.33.2 and uClibc-ng 1.0.40. In September 2021, information about the vulnerability was sent to CERT/CC for coordinated preparation of fixes. In January 2022, details about the problem were shared with over 200 manufacturers collaborating with CERT/CC. In March, an attempt was made to reach out separately to the uClibc-ng project maintainer, but he replied that he was unable to fix the vulnerability independently and recommended publicly disclosing the issue, hoping to receive assistance in developing a fix from the community. NETGEAR announced the release of an update addressing the vulnerability.
Source: opennet.ru
