Maksim Kabakou - Fotolia

Forescout reports 33 new TCP/IP vulnerabilities

The lack of consistent updates (and the open source nature of the stacks) make the Amnesia:33 vulnerabilities difficult to fix as well as make it difficult to comprehend the full impact.

Forescout Technologies disclosed 33 new vulnerabilities, including four remote code execution flaws, in four different open source TCP/IP stacks used by major IoT, OT and IT device vendors, according to a report published Tuesday.

The report, authored by Forescout researchers Stanislav Dashevskyi, Daniel dos Santos, Jos Wetzels and Amine Amri, is part of the cybersecurity company's Project Memoria initiative. The initiative, according to the report, "aims at providing the community with the largest study on the security of TCP/IP stacks." The new vulnerabilities, dubbed "Amnesia:33," were discovered during an analysis of seven open source TCP/IP stacks, including uIP, picoTCP, FNET, Nut/Net, IwIP, CycloneTCP and uC/TCP-IP.

Thirteen of the Amnesia:33 vulnerabilities were found on uIP, while 10 were discovered on picoTCP, 5 on FNET and 5 on Nut/Net. The vulnerabilities have the capability to impact "operating systems for embedded devices, systems-on-a-chip, networking equipment, OT devices and a myriad of enterprise and consumer IoT devices," and the report notes that because of multiple factors, it is difficult to fully fix these vulnerabilities.

"We estimate that more than 150 vendors and millions of devices are vulnerable to AMNESIA:33. However, it is difficult to assess the full impact of AMNESIA:33 because the vulnerable stacks are widely spread (across different IoT, OT and IT devices in different verticals), highly modular (with components, features and settings being present in various combinations and code bases often being forked) and incorporated in undocumented, deeply embedded subsystems. For the same reasons, these vulnerabilities tend to be very hard to eradicate," the report said.

In addition, Forescout researchers said patching and mitigating the Amnesia:33 vulnerabilities will be challenging. "Open source code should make it easier to fix vulnerabilities. Ideally, when a new vulnerability is disclosed, any member of the project could prepare a security patch. However, during this research, we discovered that because of the many forks, branches and unsupported yet-available versions, it is difficult to get these patches applied everywhere."

The report noted that Forescout worked with ICS-CERT and the CERT Coordination Center on patching and disclosing the vulnerabilities, as well as communicating with affected vendors. In addition, GitHub's security team assisted with identifying and contacting impacted TCP/IP repositories. However, Forescout researchers noted that only some of the stacks have developed patches for the flaws. According to the report, no official patches have been issued for the vulnerabilities in the original uIP, Contiki (a uIP version) and PicoTCP projects.

Forescout vice president of research Elisa Costante told SearchSecurity that even though millions of devices are generally estimated or accounted for, it's difficult to get a true estimation of the scope here.

"We believe this is just the surface, and much, much more devices are actually affected," she said.  "And the reason why we are saying that is because actually understanding which devices are vulnerable and running these specific TCP/IP stacks is quite a challenge."

Of the 33 vulnerabilities, four have remote code execution (RCE) potential. CVE-2020-25111 results from issues with the code that processes DNS questions and responses on Nut/Net, and has a CVSS v3.1 score of 9.8; CVE-2020-24338 involves a lack of bound checks in the domain parsing function in picoTCP, and has a score of 9.8; and two vulnerabilities in uIP, CVE-2020-24336 (CVSS 9.8) and CVE-2020-25112 (CVSS 8.1), both allow attackers to corrupt memory. While the report says that the bugs were found independently, two (including 24338) had been reported in some context previously.

Overall, the vulnerabilities have, as the report notes, four categories of potential impact, including "remote code execution (RCE), denial of service (DoS via crash or infinite loop), information leak (infoleak) and DNS cache poisoning. Generally, these vulnerabilities can be exploited to take full control of a target device (RCE), impair its functionality (DoS), obtain potentially sensitive information (infoleak) or inject malicious DNS records to point a device to an attacker-controlled domain (DNS cache poisoning)."

When asked about whether open source TCP/IP stacks should stop being used, Costante said, "not at all."

"That's not the message. The message is that we should, as a community, address several challenges. The first one is to make the software more secure. Some of those bugs are bugs from the 90s. That's why we are calling it Project Memoria because it brings back memories of bugs back in the beginning in IT systems. The fact that there's IoT means that it has to be lightweight, but lightweight doesn't mean less secure. We are not saying you need to put encryption on top of this, we are saying you have to put attention in validating the input, controlling that you are looking at the right piece of memory, et cetera. All of these things can be done at the development level," she said.

As for why the report did not find any vulnerabilities in the lwIP, CycloneTCP and uC/TCP-IP stacks, the authors observed that "the three stacks have very consistent bounds checking and generally do not rely on shotgun parsing, one of the most common anti-patterns we identified."

The findings call back to Ripple20, a series of 19 zero-day vulnerabilities that involved the Treck TCP/IP stack, and devices continued to be plagued by the vulnerabilities months after they were reported.

Costante pointed out that security extends past what most people think security is -- and goes all the way to the development level.

"People thing that security means heavy procedure around it, and encryption, and key management systems which are very heavy to run, but this is not the case. Here, the problem is really at basic development hygiene."

Dig Deeper on Application and platform security