Dewayne Geraghty
2017-Aug-17 03:50 UTC
IPSEC anomaly on FreeBSD11.1S when specifying specific port in policy rules.
I was about to send to @freebsd-stable until I realised that there are security implications for folks that may be using this, thinking that their confidential material is protected, which may not be entirely correct. --- Would appreciate others testing/confirming TCP over ESP as it seems to have a problem on 11.1Stable when specifying a specific port in policy. Performing this simple netcat test>From Origin 10.0.7.6ipfw 1 zero ; echo hi | nc -4nv -w 2 10.0.7.91 5000 ; ipfw show 1 Connection to 10.0.7.91 5000 port [tcp/*] succeeded! 00001 8 736 allow esp from any to any 00001 0 0 allow udp from any to any dst-port 5000 00001 0 0 allow udp from any 5000 to any 00001 0 0 allow tcp from any to any dst-port 5000 00001 1 60 allow tcp from any 5000 to any>From Destination 10.0.7.91ipfw 1 zero ; ipfw 2 zero ; ipfw 3 zero ; nc -l 10.0.7.91 5000 ; ipfw show 1-3 00002 0 0 allow tcp from any 5000 to any via enc0 00002 0 0 allow tcp from any 5000 to any via lo0 00002 1 60 allow tcp from any 5000 to any via white 00003 8 736 allow esp from any to any 00003 0 0 allow udp from any to any dst-port 5000 As can be observed there is a return packet that is not, but should be sent over esp. Confirmed via tcpdump on destination 11:23:53.401156 IP 10.0.7.6 > 10.0.7.91: ESP(spi=0x00024f19,seq=0x4c), length 72 11:23:53.401182 IP 10.0.7.91.5000 > 10.0.7.6.23406: Flags [S.], seq 1954279591, ack 2061987609, win 65535, options [mss 1452,nop,wscale 6,sackOK,TS val 2210679095 ecr 2684286289], length 0 11:23:53.401381 IP 10.0.7.6 > 10.0.7.91: ESP(spi=0x00024f19,seq=0x4d), length 72 11:23:53.401406 IP 10.0.7.91 > 10.0.7.6: ESP(spi=0x00024f0f,seq=0x19), length 72 11:23:53.402241 IP 10.0.7.6 > 10.0.7.91: ESP(spi=0x00024f19,seq=0x4e), length 72 11:23:53.402355 IP 10.0.7.6 > 10.0.7.91: ESP(spi=0x00024f19,seq=0x4f), length 72 11:23:53.402369 IP 10.0.7.91 > 10.0.7.6: ESP(spi=0x00024f0f,seq=0x1a), length 72 11:23:53.402381 IP 10.0.7.91 > 10.0.7.6: ESP(spi=0x00024f0f,seq=0x1b), length 72 11:23:53.402682 IP 10.0.7.6 > 10.0.7.91: ESP(spi=0x00024f19,seq=0x50), length 72 Still on destination, the policy rules in ipsec.conf contain: # udp spdadd 10.0.7.91/32[5000] 10.0.7.6/32[any] udp -P out ipsec esp/transport/10.0.7.91-10.0.7.6/require; spdadd 10.0.7.6/32[any] 10.0.7.91/32[5000] udp -P in ipsec esp/transport/10.0.7.6-10.0.7.91/require; # tcp spdadd 10.0.7.91/32[5000] 10.0.7.6/32[any] tcp -P out ipsec esp/transport/10.0.7.91-10.0.7.6/require; spdadd 10.0.7.6/32[any] 10.0.7.91/32[5000] tcp -P in ipsec esp/transport/10.0.7.6-10.0.7.91/require; To enable traffic to transit correctly over esp, change the third rule from spdadd 10.0.7.91/32[5000] 10.0.7.6/32[any] tcp -P out ipsec esp/transport/10.0.7.91-10.0.7.6/require; to spdadd 10.0.7.91/32[any] 10.0.7.6/32[any] tcp -P out ipsec esp/transport/10.0.7.91-10.0.7.6/require; While on the origin side, /etc/ipsec.conf contains: # udp 5000 spdadd 10.0.7.91/32[5000] 10.0.7.6/32[any] udp -P in ipsec esp/transport/10.0.7.91-10.0.7.6/require; spdadd 10.0.7.6/32[any] 10.0.7.91/32[5000] udp -P out ipsec esp/transport/10.0.7.6-10.0.7.91/require; # tcp 5000 spdadd 10.0.7.91/32[5000] 10.0.7.6/32[any] tcp -P in ipsec esp/transport/10.0.7.91-10.0.7.6/require; spdadd 10.0.7.6/32[any] 10.0.7.91/32[5000] tcp -P out ipsec esp/transport/10.0.7.6-10.0.7.91/require; The destination kernel has options IPSEC options IPFIREWALL while the origin kernel has options IPSEC options IPFIREWALL options IPFIREWALL_NAT The sender has been used been extensively used with ipsec since 2014, its 9.2Stable Feb22, 2014; previously as a front for strongswan et al. icmp was also used over esp using the same association rules and they worked correctly. BTW: I did send this to secteam at freebsd.org but it bounced with this explanation: http://www.openspf.org/Why?s=mfrom;id=dewayne.geraghty at heuristicsystems.com.au;ip=8.8.178.116;r=kris at pcbsd.org and my spf records are: heuristicsystems.com.au. 3600 IN TXT "v=spf1 mx ip4:203.41.22.115 -all" heuristicsystems.com.au. 3600 IN TXT "v=spf2.0/mfrom mx ip4:203.41.22.115 -all I don't think that this is the right advice??? Kind regards, Dewayne.
Andrey V. Elsukov
2017-Aug-21 12:09 UTC
IPSEC anomaly on FreeBSD11.1S when specifying specific port in policy rules.
On 17.08.2017 06:50, Dewayne Geraghty wrote:> I was about to send to @freebsd-stable until I realised that there are > security implications for folks that may be using this, thinking that > their confidential material is protected, which may not be entirely correct.Hi, I think this was broken by me in r275710. This SYN+ACK packet is sent by syncache code directly when PCB is not yet created. And due to missing inpcb pointer this packet is considered as "forwarded" and thus TCP ports are not filled properly for SP lookup. We can fix this in two ways: 1. Always fill ports. This will add a small extra overhead, but will solve restriction described in the setkey(8): NOTE: upperspec does not work in the forwarding case at this moment, as it requires extra reassembly at forwarding node, which is not implemented at this moment. 2. Resurrect the flags argument and always fill ports when not forwarding. What is the best solution? -- WBR, Andrey V. Elsukov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20170821/847f493b/attachment.sig>