CLAV-SA-0284 Ripple20: Multiple vulnerabilities in Treck TCP/IP stack library used in multiple IoT/IIoT productsBack to list
|Summary||Ripple20: Multiple vulnerabilities in Treck TCP/IP stack library used in multiple IoT/IIoT products|
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.
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.
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.
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 , which increases the entropy that an out-of-band attacker needs to guess by 2^16 = 65536 times.
Facts about Ripple20 are not yet all public. This document will be updated.