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
kernel-panic69
DD-WRT Guru


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

PostPosted: Thu Dec 26, 2019 20:56    Post subject: Reply with quote
End result is now that this mitigation is a selectable option defaulted to enabled per executive decision by Brainslayer. Acceptable solution and a win-win for all. It does not, however fix the underlying larger-picture problem(s) by design, but everyone should be happy for now.
_________________
"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
Sponsor
ironstaff
DD-WRT User


Joined: 11 Oct 2019
Posts: 157

PostPosted: Thu Dec 26, 2019 23:17    Post subject: Reply with quote
The vulnerability exploits a characteristic of tcp/ip and isn’t a Linux issue or a ‘bug’, to be brutally honest. IP was never initially designed with privacy or security in mind so most related mitigations are like band-aid on a wound.

I’m glad it stayed in the firmware as a default but is optional, as should have been the case from the start like I suggested in my original ticket on SVN.
kernel-panic69
DD-WRT Guru


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

PostPosted: Thu Dec 26, 2019 23:46    Post subject: Reply with quote
TCP/IP suite is probably the best thing we have. Everything else would be a nightmare in today's networking environment. I remember when some networks were still using IPX and Novell. I don't miss Novell NetWare whatsoever.
_________________
"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
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12814
Location: Netherlands

PostPosted: Fri Dec 27, 2019 9:55    Post subject: Reply with quote
kernel-panic69 wrote:
TCP/IP suite is probably the best thing we have. Everything else would be a nightmare in today's networking environment. I remember when some networks were still using IPX and Novell. I don't miss Novell NetWare whatsoever.


YES Novell SFT 3 my first task as system admin Very Happy

_________________
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
Alozaros
DD-WRT Guru


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

PostPosted: Fri Dec 27, 2019 10:48    Post subject: Reply with quote
hahaha use to play diablo over IPX with the locals......Razz and this one, NCP over IPX times "fek" those corporate printers m8...was a nightmare...

so, my initial tests on the shitshow ware those
echo 1 > /proc/sys/net/ipv4/conf/<interface>/rp_filter
and
iptables -t raw ! -i <vpn interface> -d <local IP / netmask of interface> -j DROP

and nmap didn't show anything that bad as you can see at the begging of the shit show...thread... Razz
i haven't tested 791 yet, and i guess the second rule from above is BS default...

Im not using a VPN server only VPN client...if i have more time ill do more tests,
but currently cant play with the units...too busy...

The thing i also wonder now...regrating those new rules added, any reports on performance side?

do i still need that rule running VPN client only ?

iptables -t nat -I POSTROUTING -o br0 -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j MASQUERADE

_________________
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


Last edited by Alozaros on Fri Dec 27, 2019 13:29; edited 1 time in total
kernel-panic69
DD-WRT Guru


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

PostPosted: Fri Dec 27, 2019 12:16    Post subject: Reply with quote
egc wrote:
kernel-panic69 wrote:
TCP/IP suite is probably the best thing we have. Everything else would be a nightmare in today's networking environment. I remember when some networks were still using IPX and Novell. I don't miss Novell NetWare whatsoever.


YES Novell SFT 3 my first task as system admin Very Happy


I remember the God-awful early days of Linux and NetWare functionality. NetWare 3.x, 4.x, 5.x ... and I don't miss any one of them. I want to say it was around 5.x, maybe 4.1, but that's been too many days gone by.

_________________
"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
ironstaff
DD-WRT User


Joined: 11 Oct 2019
Posts: 157

PostPosted: Fri Dec 27, 2019 15:32    Post subject: Reply with quote
Alozaros wrote:
hahaha use to play diablo over IPX with the locals......Razz and this one, NCP over IPX times "fek" those corporate printers m8...was a nightmare...

so, my initial tests on the shitshow ware those
echo 1 > /proc/sys/net/ipv4/conf/<interface>/rp_filter
and
iptables -t raw ! -i <vpn interface> -d <local IP / netmask of interface> -j DROP

and nmap didn't show anything that bad as you can see at the begging of the shit show...thread... Razz
i haven't tested 791 yet, and i guess the second rule from above is BS default...

Im not using a VPN server only VPN client...if i have more time ill do more tests,
but currently cant play with the units...too busy...

The thing i also wonder now...regrating those new rules added, any reports on performance side?

do i still need that rule running VPN client only ?

iptables -t nat -I POSTROUTING -o br0 -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j MASQUERADE


I would have preferred rp_filter rule even though ack/rst responses and inference may be possible, packet injection and dns spoofing wouldn't be possible as long as ipv6 is disabled (which it is by default). This is still not good as it kind of makes vpn tunnel useless if it cannot protect against active connection guesses. This mitigation method, however, is not performant for dd-wrt.

Yes, BS chose to use the second rule. It is more effective because it decimates possibility of attacker receiving ack/rst responses after npinging range for local vpn ip then pointing website ip to local vpn ip for active connection inferences. It also doesn’t allow for packet injection or dns spoofing. More effective than using rp_filter.

You don't need this rule

Code:
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j MASQUERADE


if running vpn client as it is a point to point connection from your router to vpn provider. Needed just for opnvpn server setups where router clients are needed to be reached via vpn server tunnel by remote end router.
Alozaros
DD-WRT Guru


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

PostPosted: Fri Dec 27, 2019 16:46    Post subject: Reply with quote
ironstaff thanks for clarifying this...
yep im running client only but i was thinking to explore VPN site to site option, just pure curiosity...

now without VPN
just noticed...this...on FORWARD chain
i usually have a lots of dropped packets here, now nothing comes up...those are default dropped packets non-related, not-established...
0 0 DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0

and have a fair amount of dropped on INPUT chain
5977 407K DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0

currently im not using my VPN.....

_________________
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


Last edited by Alozaros on Fri Dec 27, 2019 22:11; edited 1 time in total
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12814
Location: Netherlands

PostPosted: Fri Dec 27, 2019 16:58    Post subject: Reply with quote
That is correct, as the OVPN server does no NAT'ting.

I think, when using a site-to-site VPN where you usually control both ends, you do not even have to use NAT on the clients side, you can set a static return route on the server and then you do not need that rule on the server side at all.

_________________
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
Alozaros
DD-WRT Guru


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

PostPosted: Fri Dec 27, 2019 22:06    Post subject: Reply with quote
egc, sry about the confusion those results are without VPN....i wasn't clear nuff...
_________________
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
arran
DD-WRT Novice


Joined: 05 Sep 2016
Posts: 8

PostPosted: Thu Jan 16, 2020 10:51    Post subject: Reply with quote
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.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12814
Location: Netherlands

PostPosted: Thu Jan 16, 2020 11:18    Post subject: Reply with quote
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.

_________________
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: Sun Feb 23, 2020 6:38    Post subject: Reply with quote
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);
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12814
Location: Netherlands

PostPosted: Sun Feb 23, 2020 9:48    Post subject: Reply with quote
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

_________________
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
Alozaros
DD-WRT Guru


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

PostPosted: Sun Feb 23, 2020 10:39    Post subject: Reply with quote
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

_________________
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
Goto page Previous  1, 2, 3, 4, 5, 6  Next Display posts from previous:    Page 4 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