From owner-freebsd-security@freebsd.org Thu Aug 17 03:51:25 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39310DC6C73 for ; Thu, 17 Aug 2017 03:51:25 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from hermes.heuristicsystems.com.au (hermes.heuristicsystems.com.au [203.41.22.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.heuristicsystems.com.au", Issuer "Heuristic Systems Type 4 Host CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7628983767 for ; Thu, 17 Aug 2017 03:51:20 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.15.2/8.15.2) with ESMTPSA id v7H3qdqD008775 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 17 Aug 2017 13:52:40 +1000 (AEST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) X-Authentication-Warning: b3.hs: Host ewsw01.hs [10.0.5.3] claimed to be [10.0.5.3] To: "freebsd-security@freebsd.org" From: Dewayne Geraghty Subject: IPSEC anomaly on FreeBSD11.1S when specifying specific port in policy rules. Message-ID: <321a4895-8c4e-8261-eedf-c93bccd696d0@heuristicsystems.com.au> Date: Thu, 17 Aug 2017 13:50:13 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-AU X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 03:51:25 -0000 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.6 ipfw 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.91 ipfw 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@freebsd.org but it bounced with this explanation: http://www.openspf.org/Why?s=mfrom;id=dewayne.geraghty@heuristicsystems.com.au;ip=8.8.178.116;r=kris@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.