Is there a fix in the works for CVE-2019-14899?

For more information, please see:
https://linux.slashdot.org/story/19/12/ ... onnections

and

https://cve.mitre.org/cgi-bin/cvename.c ... 2019-14899

and details of the exploit at:

http://qntra.net/2019/12/vpn-breaking-z ... ms-burned/

Daniel

Thanks for posting this, I was about to start a new thread myself when I saw yours. I'm surprised to see nobody jumping out the windows left and right, this is a serious vulnerability. Any official news on this Mikrotik people ?

Good that RouterOS v6 use relatively old Linux Kernel that nobody cares about anymore.

I wouldn't worry about this one. This requires a "network adjacent attacker" (layer 2), so why do you have attackers next to your router? If you're seriously worried about this, turn on strict reverse-path filtering and block private IP ranges from WAN interfaces (which is a good practice regardless).

I don't mean to be rude but with attacks coming from so many different vectors in our modern world, I don't consider the LAN interfaces as the "safe side" anymore. Vulnerable stuff is flying off the shelves and popping up in our "trusted" networks, as we all know. Pivoting off these things to launch layer 2 attacks can be trivial at times, which is why I believe this vulnerability deserves a bit of our attention.

If you have untrusted devices on your layer 2 network then they can easily ARP spoof, DNS spoof, etc and do a full MITM on you much more easily than exploiting this vulnerability.

As I understand it, it's really more misconfiguration than anything else. You have some remote network reachable over VPN. And attacker connected to your other interface (e.g. WAN, after conquering ISP's network), can send spoofed packets from remote network's range. And router will accept them, because why wouldn't it, that could be perfectly valid asymmetric routing config. If it's not, then there should be strict RP filter and problem solved.

Trouble is when you can't use strict RP filter, e.g. in multi-WAN config. There's loose one, but I'm not sure if it actually does anything useful. RouterOS manual says that it's RFC3704's Loose Reverse Path, but the description there is not very convincing. If I'm not misintepreting the part about default route, it sounds that if there's one, it will allow everything. I'll have to test that, or someone who knows better can save me some time and tell me.

In RouterOS you can turn on reverse path filtering:
/ip settings set rp-filter=yes

Shouldn't that be '/ip settings set rp-filter=strict', Normis? Or are they synonyms?