CVE-2020-10136

Vendor solution

Customers should apply the latest patch provided by the affected vendor that addresses this issue and prevents unspecified IP-in-IP packets from being processed. Devices manufacturers are urged to disable IP-in-IP in their default configuration and require their customers to explicitly configure IP-in-IP as and when needed.

Red Hat statement

The IP-in-IP encapsulation is 'in the clear' tunnel protocol between two hosts. When the module is loaded, the system will be in an 'any-to-any' routing state. It will accept any "IP in IP" packets and forward them through the system routing chains. No authentication, encryption or restrictions is created between endpoints by the kernel module. Until a configuration rule is set, any system that can send "IP in IP" packets to an unconfigured system with the ipip kernel module loaded will be unwrapped and forwarded. There is an area of opportunity between module loading and configuration that may allow for an attacker to abuse this flaw. When a tunnel device is created this will restrict the source and destination of the tunnelled packets. The content of the tunnelled data remains unencrypted and unauthenticated. Red Hat Product Security strongly recommends using authenticated and encrypted tunnels such as IPSec, VPN or libreswan if tunnelling between networks is required.

Red Hat mitigation

Systems that have IP in IP kernel modules loaded will need to unload the "ipip" kernel module and blacklist it to prevent the module from being used a fix has been provided ( See https://access.redhat.com/solutions/41278 for a guide on how to blacklist modules). Take careful consideration that if unloading and blacklisting the module, this may create a one-time attack vector window for a local attacker. Consider using an alternative authenticated and encrypted tunnelling protocol until a suitable solution is developed.