CVE-2019-14899
-
Is pfSense vulnerable to CVE-2019-14899 with fully encrypted site to site VPN links? I'm getting conflicting information that while FreeBSD is vulnerable, pf might be providing the reverse path filtering feature required to protect against it.
If pf is indeed capable of blocking the attack, what minimum settings are required to force pfSense away from the weak host model?
EDIT: If I'm not mistaken, adding a BLOCK rule to all external interfaces for all traffic destined for the (private IP space) VPN networks should be sufficient to stop this attack?
Thanks!
-
I'd wait after it's officially assigned. The CVE number itself isn't yet registered with mitre and only reserved. Neither was there an ack from FreeBSD nor OpenVPN/IPSEC etc. concerning the thing. Not that this is a non-issue but more along the lines about "what should acutally be done to prevent it".
As far as I understand the issue it is not exactly a VPN problem but a routing issue (that's why OS' kernel developers are looking into this) and has very specific targets, namely an attacker that sits "virtually next to you" or control the public WiFi AP at your local coffee shop where you're connecting to your company's VPN. If the attacker controls the AP then he can inject packets into your data stream to probe, which virtual IP you got from your VPN (e.g. 10.0.8.123) and then send forged packets to this address with falsified data probing for e.g. a certain webserver you're visiting. If that connection isn't secured via TLS it is / could be possible to inject false data into your server response. One answer to that CVE I read was about the possibility to forge poisened DNS info into your data stream.
So not the VPN itself is compromised but it's more a routing stack thing and your client PC accepting packets on e.g. its wireless interface (unencrypted) that are addressed to your VPN endpoint IP but NOT actually coming from your VPN. So the stack accepts packets for your virtual IP 10.0.8.123 that actually come from wireless/wired interface e.g. wifi0 instead of your ovpnc0 interface and by thus creating the possibility to inject false data.
Is pfSense affected? I think that heavily depends on what end you're running it and what your use case is. A RAS server for dial-in users to your company "could" be affected because - as shown - the attack isn't based on OpenVPN or FreeBSD/pfSense being the endpoint of the tunnel but the attack comes from sitting right next to/in front of the client you want to attack e.g. your coffee house's access point/free WiFi. But that's only what I got from the doc so far, hopefully s/o with more development background can chime in to that ;)
-
@JeGr Thanks for the reply.
Right, malicious upstream is (sadly) always a possibility we have to deal with, but the main concern right now is more with IPSec protected site to site links over common Internet infrastructure (i.e. at remote sites, malicious neighbors could easily exist due to ISP link aggregation / ISP network design -- e.g. many "business class" ISPs that are the only option at some of our remote locations have built-in poorly secured gateway WiFi (!) on the same network subnet as the VPN router WAN port...).
As long as pfSense blocks the injection from WAN side when configured to block any traffic from the WAN interface to the VPNed IPs, I think we're OK, but as you say details on the actual attack are scarce -- I've been having to read a lot between the lines and while my initial instinct was that it only affects multihomed standard client machines, not firewalling routers like pfSense or our custom iptables-based machines, I'd still like confirmation the core site to site links (and devices attached to those VPNs) driven by the firewalling routers aren't affected.
-
@tpearson-raptor said in CVE-2019-14899:
As long as pfSense blocks the injection from WAN side
pfSense blocks anything on the WAN side until told otherwise. So IMHO it is not so much a problem for %anyVPN% in Site2Site configurations (you don't normally have anyone attacking you 'sitting besides/in front' your upstream WAN line to run this kind of attack) but dial-in scenarios.
-
From reading https://seclists.org/oss-sec/2019/q4/122 their test case was a compromised AP, which is probably a more common worry than anything involving pfSense. For example if you connect a workstation to a rogue AP at a cafe, they might be able to glean some info about your connections while using a VPN.
Granted it's still rather early in the AM and I might be overlooking something, but I don't think it would be a worry in our use case. Still, if there is anything updated from the FreeBSD side, we'll pick it up eventually either way.
-
Would tls-auth have any affect on this issue?
-
OpenVPN is distancing themselves from the issue, indicating that the responsibility lies in the underlying networking stack.
https://openvpn.net/no-flaws-found-in-openvpn-software/ -
@awebster said in CVE-2019-14899:
OpenVPN is distancing themselves from the issue, indicating that the responsibility lies in the underlying networking stack.
https://openvpn.net/no-flaws-found-in-openvpn-software/I'm not too surprised -- the flaw from what I understand is sort of like someone opening top secret envelopes and leaving the documents lying around for random people to read (or more precisely, allowing random people to dump their own documents on that same desk). Not the fault of the courier (OpenVPN), entirely the fault of the consumer (kernel), though a bit more nuanced as I will detail below.
I think, in general, pfSense site to site VPNs are unaffected by this CVE, even assuming malicious upstream and regardless of the exact VPN software in use. What will definitely be affected are standard end user devices without a firewall enabled -- this might be a good incentive to start getting some basic firewalling set up on such devices, as fundamentally I'm leaning more toward this being a configuration problem (lack of proper firewall setup leads to malicious traffic altering machine state) vs. a general kernel level flaw.
-
The CVE was way way way more hyped than it should be. 100% a routing issue and not a "fault" at VPNs. https://github.com/stryngs/hysteria << For the answers
