Forescout and JSOF on Tuesday announced “Name:Wreck,” a set of nine vulnerabilities in four popular TCP/IP stacks, including FreeBSD. The findings are the latest research to show how complexities in the TCP/IP standards can ultimately leads to vulnerable products.
Forescout and JSOF have documented several groups of vulnerabilities in TCP/IP stacks over the past year. Forescout discovering Amnesia:33 and Name:Jack and JSOF discovering Ripple20. All of those discoveries are based, in part or whole, on vendors and open source projects misinterpreting the documents describing the TCP/IP standards, known as RFCs. Name:Wreck adds a second layer of complexity – a common misinterpretation of the DNS standards involving memory pointers and message compression.
“The RFC is an archival system, which means the main RFCs don’t get changed. Instead, they release errata, new RFCs that are on top of each other. If you look at DNS, the original document is from 1983 and then there are several other scattered documents that talk about other ways to prevent problems. Some of them mentioned the invalid compression pointers that we found here and there, but not in a centralized way and not usually talking about security,” said Daniel Dos Santos, research manager at Forescout.
By the researchers’ count, there have been at least 14 instances since the year 2000 where DNS message compression has caused vulnerabilities in a wide variety of products – everything from Cisco IP phones in 2005 to various TCP/IP stacks discovered as part of Amnesia:33 and Ripple20.
The Name:Wreck research found potential remote code execution bugs related to message compression in various versions of FreeBSD, IPNet and Nucleus Net, a denial-of-service bug related to message compression in NetX, and a host of complementary remote execution, DNS cache poisoning and denial of service bugs in Nucleus related to other factors surrounding DNS.
The IPNet vulnerability had been previously reported and addressed in latter versions of the product. However, it had never been publicly announced or given a CVE number. For a TCP/IP stack, where different vendors implement the stack and then maintain the new product themselves, Dos Santos said that lack of transparency can be a problem.
“We actually don't know who is patched and who is not, and that's one of the issues with patching without issuing CVE ID,” he said.
As part of the effort to mitigate the issues outlined in the report, JSOF and Forescout are writing their own informational RFC to address the security issues not raised by the main RFC. The hope is to alleviate some of common slipping points that lead to problems. But, Dos Santos said, the best solution might be to allow corrections to RFCs in the original documents.
“I mean I don't want to be the one telling the [Internet Engineering Task Force] how to do their work. Things have worked for more than 40 years on the internet because of the RFC systems," he said. "But indeed, I do believe that it's time that we think of an alternative."
The industry should review some of "the protocols that everybody uses with a fine-tooth comb and either create new versions where security considerations are not scattered with new documents but are in the document that people look at.”
