Standard C libraries uClibc and uClibc-ng, used in many embedded and portable devices, contain a vulnerability (no CVE assigned) that allows for fake data injection into the DNS cache, which can be exploited to spoof the IP address of any domain in the cache and redirect requests to a malicious 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 is present in devices from many manufacturers (for example, uClibc is used in firmware from 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 has not yet been disclosed.
The vulnerability is caused by the use of predictable transaction identifiers in the code that sends DNS queries. The DNS request ID was chosen by simply incrementing a counter without any additional port number randomness, allowing for DNS cache poisoning through preemptive sending of UDP packets with fake responses (the response will be accepted if it arrives before the real response and includes the correct ID). serverilt Unlike the method proposed by Kaminsky in 2008, the transaction identifier does not even need to be guessed, as it is inherently predictable (it initially starts at 1, which is incremented with each query, rather than being chosen randomly).

The specification for preventing identifier guessing recommends additionally using randomization of the source network port numbers from which DNS queries are sent, which compensates for the insufficiently large size of the identifier. When port randomization is enabled for generating fake responses, in addition to guessing the 16-bit identifier, one must also guess the network port number. In uClibc and uClibc-ng, such randomization was not explicitly included (a random source UDP port was not specified when calling bind), and its use depended on the operating system settings.
Kui raundimise vĂ€lja lĂŒlitada, on inkrementeeritava pĂ€ringu tuvastamine triviaalne ĂŒlesanne. Kuid isegi juhul, kui raundimist rakendatakse, peab rĂŒndaja lihtsalt guessima vĂ”rguporti vahemikus 32768â60999, milleks vĂ”ib kasutada massilist korraga esitatud valevastuste saatmist erinevatele vĂ”rguportidele.

Probleemi olemasolu on kinnitatud kĂ”igis viimastes versioonides uClibc ja uClibc-ng, sealhulgas kĂ”ige vĂ€rskemates versioonides uClibc 0.9.33.2 ja uClibc-ng 1.0.40. Septembris 2021 saadeti teave haavatavuse kohta CERT/CC-le kooskĂ”lastatud paranduste ettevalmistamiseks. Jaanuaris 2022 edastati andmed probleemist rohkem kui 200 tootjale, kes tegid koostööd CERT/CC-ga. MĂ€rtsis tehti katse eraldi ĂŒhendust vĂ”tta uClibc-ng projekti toetajaga, kuid ta vastas, et ei ole haavatavust iseseisvalt parandada suuteline ja soovitas probleemist avalikult teada anda, lootes saada kogukonnalt abi paranduse vĂ€ljatöötamisel. NETGEAR kuulutas tootjatest vĂ€lja vĂ€rskenduse, mis probleemi lahendab.
Allikas: opennet.ru
