*Nix Vulnerability Lets Attackers Hijack VPN Connections


Apparently linux,BSD,and macOS are all affected.

The CVE is https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14899

Which hasnt even made it to the arch security list yet:

According to the article though Arch and Manjaro are among those currently vulnerable.

Mitigation is possible according to the researchers and it can be potentially achieved by turning reverse path filtering on, by using bogon filtering —filtering bogus (fake) IP addresses — or with the help of encrypted packet size and timing.

Checkup and mitigation

( from posting https://seclists.org/oss-sec/2019/q4/122 )

Possible Mitigations

  1. Turning reverse path filtering on

Potential problem: Asynchronous routing not reliable on mobile devices,
etc. Also, it isn’t clear that this is actually a solution since it
appears to work in other OSes with different networking stacks. Also,
even with reverse path filtering on strict mode, the first two parts of
the attack can be completed, allowing the AP to make inferences about
active connections, and we believe it may be possible to carry out the
entire attack, but haven’t accomplished this yet.

  1. Bogon filtering

Potential problem: Local network addresses used for vpns and local
networks, and some nations, including Iran, use the reserved private IP
space as part of the public space.

  1. Encrypted packet size and timing

Since the size and number of packets allows the attacker to bypass the
encryption provided by the VPN service, perhaps some sort of padding
could be added to the encrypted packets to make them the same size.
Also, since the challenge ACK per process limit allows us to determine
if the encrypted packets are challenge ACKs, allowing the host to
respond with equivalent-sized packets after exhausting this limit could
prevent the attacker from making this inference.

We have prepared a paper for publication concerning this
vulnerability and the related implications, but intend to keep it
embargoed until we have found a satisfactory workaround. Then we will
report the vulnerability to oss-security () lists openwall com. We are
also reporting this vulnerability to the other services affected, which
also includes: Systemd, Google, Apple, OpenVPN, and WireGuard, in
addition to distros () vs openwall org for the operating systems affected.

Something like the following should be an easy check for the reverse path filtering:

cat /proc/sys/net/ipv4/conf/default/rp_filter

if the value returned is a '1' then everything is fine. a 0 would require changes.

Particularly changes to sysctl conf.
The following would enable 'reverse path filtering':

net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

Either at /etc/sysctl.conf or more preferably somewhere like /etc/sysctl.d/rpfilter.conf

Related information:


Since Arch has had this info for a long time - the researchers are not disclosing something new.

But since systemd use a default value of 0 - then the problems begin.

I remember from my very early days on Linux - ClarkConnect proxy server - the logging of martians. The martian packets are closely related to the reverse path but using another technique.


Am I right in saying that to exploit this vulnerability the attacker must be on the same network as you?

"This security flaw "allows a network adjacent attacker to determine if another user is connected to a VPN, the virtual IP address they have been assigned by the VPN server, and whether or not there is an active connection to a given website," according to William J. Tolley, Beau Kujath, and Jedidiah R. Crandall, Breakpointing Bad researchers at University of New Mexico."

It would of course still be an issue for those using VPNs in public settings.

1 Like

Yes - that is correct.

That is also correct.

It is easily mitigated by adding the mentioned configuration to /etc/sysctl.d/99-sysctl.conf


Wait.. so the default in manjaro is 1, we are all ok then?

I need to make this file first? I don't have it already. And then put

net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

in the file?

The preferred method is making a file called rpfilter.conf as the researchers of this exploit said. But yes, you need to make the file first.

1 Like

Thank you for replying! Do I make rpfilter.conf in the /etc/sysctl.d/and reboot is needed after that?

That is correct.:+1:

Then after you reboot type:

cat /proc/sys/net/ipv4/conf/default/rp_filter

If you have an output of 1 then everything is set correctly. If you get a 0 something isn’t right.

1 Like

Thank you so much!

1 Like

I did as your advice and after reboot I ran the command and it gave 1. Then everything is good.
Thank you again!

I cannot speak to the default across all editions. But according to the researchers, and my own installs, and what I could dig up on gitlab .. it seems the default is not implementing Reverse Path Filtering.
(it is only one of other mitigations, but seems the least destructive)
Hence the 'check' included .. and the other info so you can make your own decisions.
I am still not fully informed of all of this .. I simply came across it recently and decided to share.

1 Like

Systemd uses default value of 2 and they have reasons for it. 0 is kernel default.

You are probably correct - I meant kernel.

My system had the value of 0 - I am not in the danger zone though :slight_smile:

Isn't this affecting also IPv6 and the workaround only applies to IPv4 ?


However, we recently discovered that the attack also works against IPv6, so turning reverse path filtering on isn't a reasonable solution

... but neither of the other solutions are exactly actionable ...

1 Like

Thanks for clarifying this. I read a bit about, but some of the stuff just got over my head in some regards ...

.. whenever I have time I might investigate the bogon route .. but I suspect some sort of fix will probably drop upstream, such as in a systemd update.

EDIT - This is all ongoing, and you reminded me to look and see more recent updates:

  • This attack works regardless of if you have a VPN or not. The attacker just needs to be able to
    send packets to the other host. It's not systemd specific. It can also occur because the user deliberately
    configured the rp_filter that way (that's sometimes the case if PBR (Policy Based Routing) is configured.
    The default for rp_filter is strict. For further information on the matter see ip-sysctl.txt[2]
    and RFC 3704 Section 2.4[3]. For now, just create a file /etc/sysctl.d/51-rpfilter.conf with the content
  • You can solve the problem generally for IPv6 by using the rpfilter iptables or nftables module in *mangle

Just globally one rule is needed.

..I havent had time yet, but see more here:

1 Like

Not the best of solutions, but if you’re not using IPv6 you can always disable it.

Only problem I can see with this in long term is with IPv4 being exhausted (when IANA release final few reserved blocks) there will be less and less bogons to filter out, if you black hole them you’ll be eventually killing portions of genuine IPs.

On the plus side however, you’ll just be left needing to filter martians.

1 Like

Forum kindly sponsored by