CVE-2019-14899: Suggested VPN Vulnerability Mitigation

Post new topic   This topic is locked: you cannot edit posts or make replies.    DD-WRT Forum Index -> Contributions Upload
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
BrainSlayer
Site Admin


Joined: 06 Jun 2006
Posts: 7463
Location: Dresden, Germany

PostPosted: Sun Feb 23, 2020 10:55    Post subject: Reply with quote
i dont know what to fix here. the interface doesnt exist and this is why this is returned. so if the interface doesnt exist nothing can work anyway. so your openvpn setu seem to be broken or modified in a strange way, so that this interface has a different name or simple wasnt existing while running that code
_________________
"So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Sponsor
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14102
Location: Texas, USA

PostPosted: Sun Feb 23, 2020 12:18    Post subject: Reply with quote
Alozaros wrote:
well it smells like my bug...
42460 not letting me to update/boot without reset from 42054
tried almost everything but not that, sadly after 35 hours in total
struggle, ill wait for the next build
thx for sharing it


Disable the mitigation, move forward with 42460.

_________________
"Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT
Pogo - A minimal level of ability is expected and needed...
DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)

----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 6388
Location: UK, London, just across the river..

PostPosted: Sun Feb 23, 2020 13:06    Post subject: Reply with quote
although im sick of try's , its so tempting....

as i said WAN never comes up nor DHCP... so it very likely source of the issue...will do on next update..i guess...

_________________
Atheros
TP-Link WR740Nv1 ---DD-WRT 55179 WAP
TP-Link WR1043NDv2 -DD-WRT 55303 Gateway/DoT,Forced DNS,AP Isolation,Ad-Block,Firewall
TP-Link WR1043NDv2 -DD-WRT 55303 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear R7800 --DD-WRT 55363 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55363 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55363 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
stalonge
DD-WRT Guru


Joined: 21 Jul 2006
Posts: 1898
Location: Fortaleza Ce Brazil

PostPosted: Sun Feb 23, 2020 13:08    Post subject: Reply with quote
Mine openVPN is working fine ... 42490 .. since always

Wireguard works just fine in R7800 .. Its not working in Broadcom units ( WHZ1750 ) It connects but no Nat


@ BS .. Samba is working in Linux box and Windows . but in FTPserver and Android devices ( remote access ) it is not getting the files in directories .. since a mounth ago .



Very Happy Very Happy

_________________
DDwrt ...it rocks ....

1 R7800 54420 AP Wireguard webserver JFFS SAMBA FTP usb HD Mesh
1 R7800 54420 Cli Mesh
1 WZR1750 54389 AP Webserver Samba Wireguard
1 TP link Archer C7v5 54420 Cli Mesh
1 DD x86_64 48296 Gateway Samba Ftp Webserver
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12812
Location: Netherlands

PostPosted: Sun Feb 23, 2020 16:25    Post subject: Reply with quote
stalonge wrote:
Mine openVPN is working fine ... 42490 .. since always

Wireguard works just fine in R7800 .. Its not working in Broadcom units ( WHZ1750 ) It connects but no Nat


@ BS .. Samba is working in Linux box and Windows . but in FTPserver and Android devices ( remote access ) it is not getting the files in directories .. since a mounth ago .



Very Happy Very Happy


@Stalonge we are getting off topic, but do you mean the NAT out via the WAN is missing (so that your wireguard clients do not have internet access?)

If so just review Setup/Networking the oet1 interface should be unbridged and have Masquerade/NAT enabled.
Newer builds post 40267 should do this automatically.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12812
Location: Netherlands

PostPosted: Sun Feb 23, 2020 16:32    Post subject: Reply with quote
egc wrote:
stebie wrote:
egc wrote:
arran wrote:
CVE-2019-14899 Mitigation setting in firmware
Firmware: DD-WRT v3.0-r41954 std (01/09/20)
has caused a bit of a problem for me that I think I solved and I want to share.

I just bought a new R7000P Netgear router and after swapping the stock Netgear firmware with DD-WRT I manually re-entered all my config.

DHCP stopped working. If I set a static address, everything was working. After a lot of investigation disabling CVE-2019-14899 Mitigation allowed DHCP to work again.


Hmm, if that would be the case I suppose we would have seen more reports mentioning this, so I would not exclude another cause of your problem.


I was bitten by this bug, having just upgraded from "DD-WRT v3.0-r41321 std (10/14/19)" on my Netgear R8000 to "DD-WRT v3.0-r42460 std (02/20/20)" .

Code:
root@DD-WRT:~# iptables -nvL -t raw
Chain PREROUTING (policy ACCEPT 51555 packets, 21M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       0    --  !tun1  *       0.0.0.0/0            10.8.0.0/24
 3306 1046K DROP       0    --  !tun1  *       0.0.0.0/0            255.255.255.255

Chain OUTPUT (policy ACCEPT 2874 packets, 472K bytes)
 pkts bytes target     prot opt in     out     source               destination


The DROP rule on 255.255.255.255 is what appears to be the blocker. Once I delete it, DD-WRT responds to DHCP requests from br0.

Disabling the mitigation also removes these iptables rules, therefore DHCP works with the mitigation disabled, but only after a reboot (same goes for enabling the mitigation; its impact is only experienced after a reboot).

EDIT: I assume 255.255.255.255 shouldn't be there, and it may be getting there as a call to command getipmask in function create_openvpnrules(fp) in file openvpn.c may be made with a non-matching interface or an interface with no IP address at the time run, which in turn echoes "255.255.255.255/32". Not sure why this happens, but it may be avoidable if a sanity check is performed before running the iptables command, ensuring the string returned from getipmask isn't "255.255.255.255/32" .

EDIT: A proposed change to src/router/services/services/openvpn.c.

Replace line:

Code:
fprintf(fp, "iptables -t raw -I PREROUTING ! -i %s -d $(getipmask %s) -j DROP\n", ovpniface, ovpniface);


with either:

Code:
fprintf(fp, "if ! getipmask %s | grep -Eq '255\.255\.255\.255'; then iptables -t raw -I PREROUTING ! -i %s -d $(getipmask %s) -j DROP; fi\n", ovpniface, ovpniface, ovpniface);

Code:
fprintf(fp, "[ "$(getipmask %s)" != "255.255.255.255/32" ] && iptables -t raw -I PREROUTING ! -i %s -d $(getipmask %s) -j DROP\n", ovpniface, ovpniface, ovpniface);


Thanks for sharing/investigating

I am on holidays so cannot investigate this myself but I am sure you are on to something.

The create_openvpnrules(fp) is relatively new to solve another bug.

Although your patch will work, there might be even better ways to solve this.
Like making the rule conditional (only running when the interface is up) or use nvram variables (which are always available)

I will ping BS (main developer) to have a look

Thanks again


@stebie, BS has made modifications, he now uses the environment variable which is only available when the interface is up (and also excluded the use of /32, which should not be necessary but you never know)

But I have one question, are you using a non default interface?
The interface is showing as tun1 but the ip address tells me it is an openVPN Server setup which should use tun2?

Edit: forget the last question, tun2 is hard coded for openVPN server

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14102
Location: Texas, USA

PostPosted: Sun Feb 23, 2020 18:22    Post subject: Reply with quote
stalonge wrote:
Mine openVPN is working fine ... 42490 .. since always

Wireguard works just fine in R7800 .. Its not working in Broadcom units ( WHZ1750 ) It connects but no Nat


@ BS .. Samba is working in Linux box and Windows . but in FTPserver and Android devices ( remote access ) it is not getting the files in directories .. since a mounth ago .



Very Happy Very Happy


Posting information about alpha builds is irrelevant to this topic. Sort of. But thanks for the info anyway.

_________________
"Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT
Pogo - A minimal level of ability is expected and needed...
DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)

----------------------
Linux User #377467 counter.li.org / linuxcounter.net
stalonge
DD-WRT Guru


Joined: 21 Jul 2006
Posts: 1898
Location: Fortaleza Ce Brazil

PostPosted: Sun Feb 23, 2020 19:47    Post subject: Reply with quote
egc wrote:
stalonge wrote:
Mine openVPN is working fine ... 42490 .. since always

Wireguard works just fine in R7800 .. Its not working in Broadcom units ( WHZ1750 ) It connects but no Nat


Very Happy Very Happy


@Stalonge we are getting off topic, but do you mean the NAT out via the WAN is missing (so that your wireguard clients do not have internet access?)

If so just review Setup/Networking the oet1 interface should be unbridged and have Masquerade/NAT enabled.
Newer builds post 40267 should do this automatically.



Thanks for you reply .. i got it working in a broadcom unit .. The point is .. in this setup .. wireguard dd-wrt router is not the first router of this network .. it gets the ip from other dhcp router ( dmz ) .. I need to change the endpoint to real wan ip and it works .. I have a wireguard running in one r7800 a long time .. but it is the first router of this network ..

Sorry for off topic ..


Very Happy Very Happy

_________________
DDwrt ...it rocks ....

1 R7800 54420 AP Wireguard webserver JFFS SAMBA FTP usb HD Mesh
1 R7800 54420 Cli Mesh
1 WZR1750 54389 AP Webserver Samba Wireguard
1 TP link Archer C7v5 54420 Cli Mesh
1 DD x86_64 48296 Gateway Samba Ftp Webserver
stebie
DD-WRT Novice


Joined: 16 Jun 2006
Posts: 5

PostPosted: Mon Feb 24, 2020 8:22    Post subject: Reply with quote
egc wrote:
@stebie, BS has made modifications, he now uses the environment variable which is only available when the interface is up (and also excluded the use of /32, which should not be necessary but you never know)

But I have one question, are you using a non default interface?
The interface is showing as tun1 but the ip address tells me it is an openVPN Server setup which should use tun2?

Edit: forget the last question, tun2 is hard coded for openVPN server


I believe I'm using the default interface. That's why in my excerpt provided both 255.255.255.255 and 10.8.0.0/24 had an in iface of !tun1.

Code:
root@DD-WRT:~# ip a | grep tun
13: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc sfq state UNKNOWN qlen 100
    inet 10.8.2.5/24 brd 10.8.2.255 scope global tun1


My configuration is based on NordVPN's guide:
https://nordvpn.com/tutorials/dd-wrt/openvpn-gui/

Below is my OpenVPN Client's Additional Config section.

Code:
remote-cert-tls server
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping-timer-rem
reneg-sec 0
#log /tmp/vpn.log
#Delete `#` in the line below if your router does not have credentials fields and you followed the 3.1 step
#auth-user-pass /tmp/openvpncl/user.conf


Do let me know if there's anything in it that could be contributing.

@BrainSlayer: thanks for correcting my unescaped double-quotes in your implemented fix.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12812
Location: Netherlands

PostPosted: Mon Feb 24, 2020 17:08    Post subject: Reply with quote
Almost all of your settings can be set in the GUI but that is not important leave it as is.

The remote random is what probably is causing the /24 normally it is a point to point interface with a netmask of 255.255.255.255. (ifconfig shows the interface)

So I am not sure if the patch will not brake the setting of this firewall rule but I will keep an eye on things and will reverse if necessary.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
stebie
DD-WRT Novice


Joined: 16 Jun 2006
Posts: 5

PostPosted: Tue Feb 25, 2020 14:31    Post subject: Reply with quote
egc wrote:
The remote random is what probably is causing the /24 normally it is a point to point interface with a netmask of 255.255.255.255. (ifconfig shows the interface)


I think the /24 mask is what the VPN server is returning upon connection. remote-random is used to randomize server selection if you have more than one server (which I don't).

With regards to the 255.255.255.255 rule in the iptables raw table, it appears the route-up script is running before a successful connection. I can replicate it by putting in an invalid password, which won't connect therefore shouldn't trigger route-up.sh however the 255.255.255.255 rule is still added.

Unless it's not route-up.sh that's adding the rule?

I tried removing more potential factors out of the equation, including removing everything from OpenVPN Client's Additional Config and removing my cron jobs (in case there was some odd behaviour/interactions going on), however it persists.

After manually deleting the 255.255.255.255 rule, manually running stopservice openvpn and startservice openvpn does not seem to reintroduce the rule; it only appears to happen during boot time (or close to).

I've seen BS has recently changed the logic for openvpn_mit, now using env variables provided by OpenVPN, so I'll need to wait for the new beta and hope it fixes this.

EDIT: Have just tested r42514 and all appears well! Thanks again BS.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12812
Location: Netherlands

PostPosted: Tue Feb 25, 2020 15:14    Post subject: Reply with quote
stebie wrote:
egc wrote:
The remote random is what probably is causing the /24 normally it is a point to point interface with a netmask of 255.255.255.255. (ifconfig shows the interface)


I think the /24 mask is what the VPN server is returning upon connection. remote-random is used to randomize server selection if you have more than one server (which I don't).

With regards to the 255.255.255.255 rule in the iptables raw table, it appears the route-up script is running before a successful connection. I can replicate it by putting in an invalid password, which won't connect therefore shouldn't trigger route-up.sh however the 255.255.255.255 rule is still added.

Unless it's not route-up.sh that's adding the rule?

I tried removing more potential factors out of the equation, including removing everything from OpenVPN Client's Additional Config and removing my cron jobs (in case there was some odd behaviour/interactions going on), however it persists.

After manually deleting the 255.255.255.255 rule, manually running stopservice openvpn and startservice openvpn does not seem to reintroduce the rule; it only appears to happen during boot time (or close to).

I've seen BS has recently changed the logic for openvpn_mit, now using env variables provided by OpenVPN, so I'll need to wait for the new beta and hope it fixes this.


He recently changed it again, one potential problem is that the rule is not preceded with a delete rule which is good practice IMHO, I will upload a patch when I am home next week.

The real problem is that the rules are not only invoked on route up because that should work as the interface should be up by then, the problem is that the rules can also be invoked by the firewall (which is new, and was necessary because the rules where missing when the firewall restarted).
Will look into the matter next week when we have the new build to test.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
stebie
DD-WRT Novice


Joined: 16 Jun 2006
Posts: 5

PostPosted: Tue Feb 25, 2020 15:19    Post subject: Reply with quote
egc wrote:
The real problem is that the rules are not only invoked on route up because that should work as the interface should be up by then, the problem is that the rules can also be invoked by the firewall (which is new, and was necessary because the rules where missing when the firewall restarted).


Ahh, that could explain it.

Thank you also, egc, for your help.
johnnyNobody999
DD-WRT User


Joined: 10 Jan 2014
Posts: 499

PostPosted: Wed Feb 26, 2020 20:47    Post subject: Reply with quote
I don't know what I'm missing but CVE-2019-14899 Mitigation kills my OpenVPN. It has never worked for me. I get connected to the server but none of the clients can pass traffic. So far, I don't see any clues in syslog or openvpn.log.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12812
Location: Netherlands

PostPosted: Wed Feb 26, 2020 20:54    Post subject: Reply with quote
RTFM

See the link to The open VPN server setup guide in my signature.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Goto page Previous  1, 2, 3, 4, 5, 6  Next Display posts from previous:    Page 5 of 6
Post new topic   This topic is locked: you cannot edit posts or make replies.    DD-WRT Forum Index -> Contributions Upload All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum