A few days ago the news was released that in the C standard libraries uClibc and uClibc-ng, used in many embedded and portable devices, a vulnerability has been identified (with CVE not yet assigned), which allows substitution of dummy data in the DNS cache, which can be used to spoof the IP address of an arbitrary domain in the cache and redirect requests to the domain to the attacker's server.
About the problem it is mentioned that this affects various Linux firmware for routers, access points and IoT devices, as well as embedded Linux distributions like OpenWRT and Embedded Gentoo.
About vulnerability
Vulnerability is due to the use of predictable transaction identifiers in the code to send queries of DNS. The DNS query ID was chosen by simply incrementing the counter without further randomization of the port numbers, which made it possible to poison the DNS cache by preemptively sending UDP packets with bogus responses (the response will be accepted if it arrives before the response from the real server and includes the correct identification).
Unlike the Kaminsky method proposed in 2008, it is not even necessary to guess the transaction ID, since it is initially predictable (initially, it is set to 1, which increases with each request, and is not randomly selected).
to protect yourself against ID guessing, the specification further recommends the use of a random distribution of network port numbers of origin from which the DNS queries are sent, which compensates for the insufficient size of the ID.
When port randomization is enabled, to form a dummy response, in addition to selecting a 16-bit identifier, it is also necessary to select the network port number. In uClibc and uClibc-ng, such randomization was not explicitly enabled (when bind was called, a random source UDP port was not specified) and its implementation depended on the operating system configuration.
When port randomization is disabled, determining which request id to increment is marked as a trivial task. But even in the case of randomization, the attacker only needs to guess the network port from the range 32768-60999, for which he can use massive simultaneous sending of dummy responses on different network ports.
The problem has been confirmed in all current versions of uClibc and uClibc-ng, including the latest versions of uClibc 0.9.33.2 and uClibc-ng 1.0.40.
“It is important to note that a vulnerability affecting a standard C library can be quite complex,” the team wrote in a blog post this week.
"Not only would there be hundreds or thousands of calls to the vulnerable function at multiple points in a single program, but the vulnerability would affect an indefinite number of other multi-vendor programs configured to use that library."
In September 2021, information about the vulnerability was sent to CERT/CC for coordinated array preparation. In January 2022, the problem was shared with more than 200 manufacturers associated with CERT/CC.
In March, there was an attempt to separately contact the maintainer of the uClibc-ng project, but he replied that he couldn't fix the vulnerability himself and recommended public disclosure of information about the problem, hoping to get help developing a fix. of the community. From the manufacturers, NETGEAR announced the release of an update with the removal of the vulnerability.
It is important to note that a vulnerability affecting a standard C library can be quite complex. Not only would there be hundreds or thousands of calls to the vulnerable function at multiple points in a single program, but the vulnerability would affect an indefinite number of other programs from multiple vendors configured to use that library.
It is noted that the vulnerability manifests itself in devices from many manufacturers (for example, uClibc is used in firmware from Linksys, Netgear, and Axis), but since the vulnerability remains unpatched in uClibc and uClibc-ng, detailed information about devices and specific manufacturers in whose products there is a problem, until they are disclosed.
Finally if you are interested in knowing more about it, you can check the details In the following link.