Security researchers have uncovered nine vulnerabilities affecting four TCP/IP stacks impacting more than 100 million consumer and enterprise devices that could be exploited by an attacker to take control of a vulnerable system.

Dubbed "NAME:WRECK" by Forescout and JSOF, the flaws are the latest in series of studies undertaken as part of an initiative called Project Memoria to study the security of widely-used TCP/IP stacks that are incorporated by various vendors in their firmware to offer internet and network connectivity features.

"These vulnerabilities relate to Domain Name System (DNS) implementations, causing either Denial of Service (DoS) or Remote Code Execution (RCE), allowing attackers to take target devices offline or to take control over them," the researchers said.

The name comes from the fact that parsing of domain names can break (i.e., "wreck") DNS implementations in TCP/IP stacks, adding to a recent uptick in vulnerabilities such as SigRed, SAD DNS, and DNSpooq that leverage the "phonebook of the internet" as an attack vector.

They also mark the fifth time security weaknesses have been identified in the protocol stacks that underpin millions of internet-connected devices —

• URGENT/11
• Ripple20
• AMNESIA:33, and
• NUMBER:JACK

Specifically, the latest research offers a closer look at the "message compression" scheme used in the DNS protocol that "eliminates the repetition of domain names in a message" with the intent of reducing the size of messages, uncovering multiple flaws in FreeBSD (12.1), IPnet (VxWorks 6.6), Nucleus NET (4.3), and NetX (6.0.1) stacks.

In a plausible real-world attack scenario, adversaries can exploit these flaws to find their way into an organization's network via an internet-facing device that issues DNS requests to a server and exfiltrate sensitive information, or even use them as a stepping stone to sabotage critical equipment.

With the exception of IPnet, FreeBSD, Nucleus NET, and NetX have all released patches, requiring device vendors using vulnerable versions of the software to ship an updated firmware to their customers.

But as with the previous flaws, there are several hurdles to applying the fixes, what with the lack of information regarding the TCP/IP stack that runs on a device, the difficulty in delivering patches because the devices are not centrally managed, or they cannot be taken offline due to their central role in mission-critical processes like healthcare and industrial control systems.

In other words, besides the effort required to identify all the vulnerable devices, it could take a considerable amount of time before the security patches trickle down from the stack vendor to the firmware of the device.

Even worse, in some cases, it may never be feasible to push a patch, as a result of which many of the impacted devices will most likely remain exposed to attacks for years to come or until they are decommissioned.

While a quick fix may not be in sight, the bright spot in the findings is that there are mitigations that make it easier to detect attempts to take advantage of these flaws. For a start, Forescout has released an open-source script to detect devices running the affected stacks. In addition, the researchers also recommend enforcing network segmentation controls until the patches are in place and monitoring all network traffic for malicious packets that attempt to exploit flaws targeting DNS, mDNS, and DHCP clients.

The study is also expected to be presented at the Black Hat Asia 2021 conference on May 6, 2021.

"NAME:WRECK is a case where bad implementations of a specific part of an RFC can have disastrous consequences that spread across different parts of a TCP/IP stack and then different products using that stack," the researchers said.

"It is also interesting that simply not implementing support for compression (as seen for instance in lwIP) is an effective mitigation against this type of vulnerability. Since the bandwidth saving associated with this type of compression is almost meaningless in a world of fast connectivity, we believe that support for DNS message compression currently introduces more problems than it solves."