Unfixed bug in uClibc library exposes IoT devices

Yet another vulnerability could leave Internet of Things (IoT) devices exposed to DNS poisoning attacks, which occur when attackers inject fake data to redirect web traffic. The fact was recently revealed by Nozomi Networks Labs which detailed problems with the Domain Name System (DNS) implementation of all versions of uClibc and uClibc-ng, libraries used widely by Linux developers and spread among IoT products. uClibc-ng is a branch developed specifically for OpenWRT, an operating system used by routers deployed in various critical infrastructure sectors.

The failure is caused by the predictability of the transaction IDs included in the DNS requests generated by the library. Each DNS request includes as a parameter this ID, which is a unique identifier per request generated by the DNS client and which must be included in the response for it to be accepted as valid. In a DNS poisoning attack, the attacker is able to trick the DNS client into accepting a forged response, inducing it to perform network communication with an arbitrarily defined endpoint instead of the legitimate one. The attacker can then steal or manipulate transmitted information and perform other attacks. The main issue in this vulnerability is how attackers can send a response as being authentic.

According to Nozomi Networks, the alert was given by the person responsible for this library’s maintenance after noticing that they wouldn’t be able to correct the bug and suggested to disclose the vulnerability to a closed community which could help addressing the problem

The bug could affect millions of IoT devices because the uClibc and uClibc-ng libraries are used by large vendors such as Linksys, Netgear and Axis and also by Linux distributions such as Embedded Gentoo.

Open Source libraries at risk

Managing open source libraries has been posing a challenge to developers. In a recent study conducted by Veracode and focused primarely on open source libraries’ security 13 crawls of over 86 thousand repositories were assessed. After crawling over 301 thousand libraries they came to the conclusion that despite of being the base on which most software solutions are developed upon, iopen source libraries are not “a solid foundation, but something in constant development”.

Despite the dynamic nature of open source libraries, developers do not manage them as intensively – in 79% of the time, developers have not updated third-party libraries after including them in their code bases.

And what is stopping developers from updating vulnerable open source libraries? The survey found that a lack of contextual information can be a barrier. Developers reported that they need more information – for example, to understand how a vulnerable library might affect their applications – and that it takes them more than seven months just to fix 50% of known flaws. On the other hand, those with the necessary information fix that same share of flaws in just three weeks.

According to Veracode, when alerted about vulnerable libraries, developers can act quickly – about 17% of vulnerable libraries are fixed within an hour of the vulnerability alert being made; 25% are fixed within seven days.

Most open source security flaws require minor fixes – 92% of library flaws can be fixed with an update, and 69% of updates require a minor version change or even less.

Specifically, the survey asked developers what they look for when thinking about adopting a new library. Unsurprisingly, the first answer was features, because what’s the point of including a big pile of code if it serves no purpose? The second answer was licensing, followed only then by security.

Alarming is the fact that most of the open source libraries are rarely updated. Close to 50% of them, take over 21 months to get the updates, while 25% remains without update for up to 4 years.