CVE-2019-14899 vulnerability

General questions
1

Hi!

Is VyOS vulnerable? Is path / workaround available?

Thanks!

2

Hello!
From my point of view, this CVE should be divided and considered as two parts, which can be combined to a single problem:

  1. if you have control over the data channel (MITM), then you are able to detect traffic between the target and some host. There are many possible ways how to do this, which currently actively using by ISP, governments, intelligence services, and others around the World. CVE-2019-14899 described one of these ways, which may be blocked on end hosts with setting rp_filter, but this solution cannot be globally enabled on routers, as this will broke a lot of functionality.
  2. If you know session details, you can inject some data into the session by sending it to any interface on target. This is a problem at the kernel level, as such data will be considered valid. But, if you use encryption at the application level (HTTPS for example), such data will be ignored by the application. But, likely, there is still possible to kill the sessions by sending RST packets or something similar. This is bad but still old and known.

What should you know and do with this:

  1. Accept as fact: if between you and far end exist some non-trusted device or MITM, your traffic is compromised. If that device is inside your L2 domain - it is compromised twice more. We must leave with this and use encryption for sensitive connections.
  2. If you have some VPN connection, you may “protect” them by dropping traffic to address configured on VPN from other interfaces. For example, if you have OpenVPN interface vtun0 with IP 192.168.1.2, and eth0 to uplink, which you do not trust, you may block potentially malicious traffic to that interface by:
    a) Configure RP on eth0. But this can partially affect asymmetric routing.
set system sysctl custom net.ipv4.conf.eth0.rp_filter value 1

b) Set firewall rule, which will block malicious packets:

set firewall name CVE-2019-14899-BLOCK rule 10 action 'drop'
set firewall name CVE-2019-14899-BLOCK rule 10 destination address '192.168.1.2'
set interfaces ethernet eth0 firewall local name 'CVE-2019-14899-BLOCK'

c) Of course, you still able to enable RP filtration globally:

set firewall source-validation strict

But, this change could generate a lot of bad surprises - so it should be carefully tested in exact your environment and configuration.

So, we can only hope that kernel developers provide some new solutions, which will help us. But it looks like this will be not easy, at least at the IP level.