TLS Flaws Leave Avaya, Aruba Switches Open to Complete Takeover

In the latest incarnation of the TLStorm vulnerability, switches from Avaya and Aruba — and perhaps others — are susceptible to compromise from an internal attacker.

Network switches from Aruba and Avaya are vulnerable to multiple flaws that could allow attackers to remotely execute code and completely take over the devices.

Researchers from device-intelligence firm Armis found five vulnerabilities — two flaws in Aruba switches and three flaws in Avaya switches — that could be used to compromise networks that allow some outsider access, even with limited rights. The flaws can be exploited by a user of a captive portal or authentication server, researchers explained.

Worryingly, in looking at the details of the bugs, the three Avaya bugs are zero-click, requiring no authentication or user interaction to exploit. One of them affects an end-of-life device and won’t be receiving a patch.

Three of the vulnerabilities originate with improper handling of errors produced by a third-party library for implementing TLS produced by the Internet of Things (IoT) cybersecurity firm Mocana.

Because switches are typically not Internet-facing, the vulnerabilities face less danger from external hackers, but the risk is still significant, says Barak Hadad, head of research for Armis.

“These are major issues because switches act as the gatekeepers when we talk about segmentation,” he says. “When you gain control over switches, and segmentation of the network becomes invalid.”

The vulnerability details are as follows:


  • CVE-2022-23677 (9.0 CVSS score) — NanoSSL misuse on multiple interfaces (RCE)*
  • CVE-2022-23676 (9.1 CVSS score) — RADIUS client memory corruption vulnerabilities


  • CVE-2022-29860 (CVSS 9.8) — TLS reassembly heap overflow*
  • CVE-2022-29861 (CVSS 9.8) — HTTP header parsing stack overflow
  • HTTP POST request handling heap overflow (no CVE because it is in an older version)*

* These are caused by the interaction between Mocana NanoSSL and the products.

Software Supply-Chain Woes Persist
The vulnerabilities underscore the risks of the software supply chain and the potential dangers that come with using third-party components. Security flaws in the libraries on which software depends — or in this case, in the way that the software and library interact — can create or propagate vulnerabilities. On average, 78% of software codebases consist of open-source components and libraries.

In March, researchers discovered a similar set of flaws that caused security vulnerabilities in more than 150 IoT products, also caused by another third-party component.

“While the use of external libraries has many advantages, it also brings inherent uncertainty,” Armis stated in its security advisory published on May 3. “Implanting a ‘foreign’ code means the vendor is trusting it to be implemented safely, since any security issues originating in the external library are embedded within it, and automatically become security issues which the vendor has less control over.”

TLStorm, Part 2
At the heart of the Mocana-related vulnerabilities are unstable error states in the Mocana NanoSSL library that handles transport layer security (TLS) for the products’ management interface.

The issues occur because the attacker can craft network packets that cause errors in the Mocana NanoSSL library, and developers producing software for vendors do not handle the errors properly.

The result are two classes of vulnerabilities: memory corruption and state confusion.

“If you start a TLS handshake and the other side sends an improper message, if you don’t check the error code correctly, that scenario can be leveraged to gain remote code execution in some cases,” Armis’ Hadad says. “The manual clearly says that the developer should check the error, but as we know, it’s not common for developers to read through the entire manual.”

Armis has worked with Mocana, Aruba, and Avaya to remediate the issues where appropriate. The companies’ customers have been notified, and each company has released updated software. In Mocana’s case, even though the vulnerabilities are not technically caused by the software, the company has created an update anyway to avoid future flawed implementations.

“It is not a Mocana vulnerability, but nonetheless, they have published new software that makes it so you are not in a vulnerable situation just because you did not check the error code,”

Read more:

You can also read this: Russian Pushing New State-run TLS Certificate Authority to Deal With Sanctions

Leave a Reply

Your email address will not be published. Required fields are marked *