A vulnerability has been discovered (CVE not yet issued) in uClibc and uClibc-ng C standard libraries. These libraries are vastly used in IoT devices. The newly found vulnerability makes it possible to place forged data into the DNS cache, allowing to set an arbitrary IP address in that cache with the subsequent rerouting of all domain-directed queries to the malefactors’ server.
The flaw affects Linux firmware used in various routers, hotspots, and other IoT devices. It also hits Linux distributives for the embedded operating systems like Embedded Gentoo and OpenWRT. The vulnerability reveals itself in many different devices. For example, Linksys, Netgear, and Axis all use uClibc libraries. Since the vulnerability is not yet cured in uClibc and uClibc-ng, the details about specific devices and manufacturers in whose products the problem occurs are not brought to the public yet.
The vulnerability mechanism
The vulnerability comes from the usage of predictable transaction identifiers in the library-generated DNS requests. DNS request IDs are formed by simple incrementing of the counter without any additional randomization of the port numbers. This mechanism, in turn, allowed DNS cache poisoning through the proactive sending of a UDP packet with a forged response. The spoof will be accepted if it features a correct request ID and arrives before the genuine server’s response. Unlike the Kaminsky method proposed in 2008, the current approach doesn’t even require guesswork since the transaction ID is initially predictable. The initial value (1) gets incremented with each query, not chosen randomly.
Security recommendations against ID breaking include randomizing numbers of source network ports whence the DNS request. This measure must compensate for the short length of the identifier. If randomization is activated, the forgery of a 16-bit ID is not enough – hackers then would have to additionally brute-force the network port number. In uClibc and uClibc-ng, the random source UDP port didn’t show during the bind request. Therefore, the randomizer was turned off, and its application required changing settings in the operating system.
With the randomization switched off, the problem of guessing an incremented request ID becomes trivial. But even if the randomization were applied, the attackers would only need to pick up a port number from a range of 32768–60999 (Linux uses such.) They could have used a massive simultaneous sending of fake responses to different network ports yet to win against the legitimate DNS response.
History of the inquiry
The problem has been confirmed in all working versions of the uClibc and uClibc-ng, including the latest uClibc 0.9.33.2 and uClibc-ng 1.0.40. In September 2021, the information on the vulnerability was sent to CERT/CC for coordinated fixes preparation. Moreover, In January 2022, the data was delivered to more than 200 manufacturers working with CERT/CC. In March, there was communication with the uClibc-ng project support. They admitted they could not fix the vulnerability themselves and recommended disclosing the information to the community so that it could assist with the development of the fix. Nozomi Networks, the company that detected the flaw, brought the information to the public in a thorough report on May 2, 2022. In the meantime, Netgear has announced an update wherein they promise to deal with the vulnerability.
