Security Advisories

CLAV-SA-0284 Ripple20: Multiple vulnerabilities in Treck TCP/IP stack library used in multiple IoT/IIoT products

Back to list

Advisory ID	CLAV-SA-0284
Summary	Ripple20: Multiple vulnerabilities in Treck TCP/IP stack library used in multiple IoT/IIoT products
Updated	2020-06-22
First Published	2020-06-22
Impact	Not vulnerable
CVEs	CVE‑2020‑11908 CVE‑2020‑11907 CVE‑2020‑11906 CVE‑2020‑11905 CVE‑2020‑11909 CVE‑2020‑11900 CVE‑2020‑11911 CVE‑2020‑11899 CVE‑2020‑11910 CVE‑2020‑11898 CVE‑2020‑11897 CVE‑2020‑11904 CVE‑2020‑11903 CVE‑2020‑11914 CVE‑2020‑11902 CVE‑2020‑11913 CVE‑2020‑11901 CVE‑2020‑11912 CVE‑2020‑11896
Affected Products	None

 

Clavister Products not vulnerable

No Clavister product uses the Treck TCP/IP library.

From what is known so far (2020-06-22) about the vulnerabilities, no Clavister TCP/IP stack exhibits the same vulnerabilities.

Protecting other units with cOS Core

We remind the reader that much is not yet known about this series of vulnerabilites.

However, much seems to be related to fragmentation and layer size inconsistencies.

cOS Core will always:

• Check for size mismatches between L2 / IP / TCP&UDP size information and drop illegal packets
• Drop illegal-size fragments
• Drop oddly-overlapping fragments
• Drop duplicate fragments

This will likely protect against some of these attacks. But, again, much is not yet publicly known.

CVE-2020-11896 - the fragmented IP-in-IP attack

We do not recommend allowing IP-in-IP tunnels across trust boundaries, ever.

Side note: cOS Core does NOT inspect fragments (nor any other data) inside IP-in-IP tunnels.

CVE-2020-11901 - the DNS response attack

Details are not known. Author states that the packet is (mostly) RFC compliant, and we therefore assume that the response would be allowed back through a cOS Core firewall allowing outbound DNS traffic using raw UDP connections only.

• Clavister always recommends passing outbound DNS traffic through the DNS ALG, which will consistency-check DNS queries and responses and drop defective packets.
  • Using the DNS ALG is also a requirement for wildcard FQDN rules.
  • Filtering may additionally be made stricter for parts of your network, e.g. where IoT units reside, by creating a DNS profile with stricter settings, if possible.
    • Only 512-byte responses
    • Only NS, A, CNAME records. AAAA if IPv6 is in use.
    • This will disable many modern DNS security improvements, but the assumption is that simplistic IoT units do not implement those anyway. Caveat emptor.

 

• Clavister further recommends that DNS be forced through a trusted DNS cache where normalization will occur.
  • A trusted DNS cache with knowledge of your DNS zones prevents spoof attacks between your clients and your own infrastructure
  • It also prevents DNS spoof attacks of the "wpad" hostnames used for proxy autoconfiguration
  • It may also be configured as authoritative for the ".local" domain, which will prevent leaked queries from protected clients.
  • Your cache does not need to be local - it can be reached through e.g. an IPsec tunnel. Especially useful for roaming VPN users.
  • When adding DNS checks to a previously-permissive network: DNS traffic can be redirected with e.g. a Static Address Translation All-To-One rule to re-point existing clients rather than rejecting their traffic - which would cause disruption.

 

• However even without a local DNS cache, cOS Core does re-map source ports when traffic is dynamically NATed, which increases the entropy that an out-of-band attacker needs to guess by 2^16 = 65536 times.

 

Living document

Facts about Ripple20 are not yet all public. This document will be updated.

/MO