From owner-freebsd-security@FreeBSD.ORG Thu Nov 20 22:50:18 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77581F05 for ; Thu, 20 Nov 2014 22:50:18 +0000 (UTC) Received: from nschwmtas02p.mx.bigpond.com (nschwmtas02p.mx.bigpond.com [61.9.189.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0F291A56 for ; Thu, 20 Nov 2014 22:50:17 +0000 (UTC) Received: from nschwcmgw08p ([61.9.190.168]) by nschwmtas02p.mx.bigpond.com with ESMTP id <20141120225010.UNOI12338.nschwmtas02p.mx.bigpond.com@nschwcmgw08p>; Thu, 20 Nov 2014 22:50:10 +0000 Received: from hermes.heuristicsystems.com.au ([58.173.108.194]) by nschwcmgw08p with BigPond Outbound id Hyq91p00w4BhPve01yq9bF; Thu, 20 Nov 2014 22:50:10 +0000 X-Authority-Analysis: v=2.0 cv=F6HVh9dN c=1 sm=1 a=4+whva0L5pAyL5dznpY5+Q==:17 a=75Mj3Gjma4sA:10 a=N659UExz7-8A:10 a=GHIR_BbyAAAA:8 a=5y4faFyK3SkA:10 a=wa_XdYfKJJVYEBzTJNkA:9 a=pILNOxqGKmIA:10 a=4+whva0L5pAyL5dznpY5+Q==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id sAKMn40J065201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Nov 2014 09:49:05 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <546E6FDF.5090806@heuristicsystems.com.au> Date: Fri, 21 Nov 2014 09:49:03 +1100 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: jmg@funkthat.com, freebsd-security@FreeBSD.org Subject: Re: IPsec is very broken... References: <20141120213526.GH24601@funkthat.com> In-Reply-To: <20141120213526.GH24601@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:50:18 -0000 On 21/11/2014 8:35 AM, John-Mark Gurney wrote: > As I'm about to commit my AES-GCM work, I've been trying to do > some testing to make sure I didn't break IPsec. > > The first major issue I ran across was transport mode... ae@ has been > nice enough to get ICMP working in transport mode for IPv4 and IPv6, > but it looks like TCP is still broken. I haven't tested UDP yet... > So, IPsec even w/o crypto is fundamentally broken here... It's clear > that not many people run transport mode... > > If someone could create a good test suite that ensures makes sure basic > IPsec traffic passes, that would be a huge win for us. The tests > should test a complete cross product of: { tunnel, transport } x > { TCP, UDP, ICMP, any others? } x { IPv4, IPv6 }. Please add to this > list. > > There is a lock order reversal which someone should look at: > # setkey -DP > lock order reversal: > 1st 0xffffffff817fc658 sptree (fast ipsec security policy database) @ netipsec/key.c:2453 > 2nd 0xffffffff818bd920 rawcb (rawcb) @ netipsec/keysock.c:303 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001de9d330 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de9d3e0 > witness_checkorder() at witness_checkorder+0xdad/frame 0xfffffe001de9d470 > __mtx_lock_flags() at __mtx_lock_flags+0xa8/frame 0xfffffe001de9d4c0 > key_sendup_mbuf() at key_sendup_mbuf+0xb0/frame 0xfffffe001de9d500 > key_spddump() at key_spddump+0x188/frame 0xfffffe001de9d540 > key_parse() at key_parse+0x8fa/frame 0xfffffe001de9d740 > key_output() at key_output+0xeb/frame 0xfffffe001de9d7a0 > sosend_generic() at sosend_generic+0x405/frame 0xfffffe001de9d850 > kern_sendit() at kern_sendit+0x20b/frame 0xfffffe001de9d900 > sendit() at sendit+0x129/frame 0xfffffe001de9d950 > sys_sendto() at sys_sendto+0x4d/frame 0xfffffe001de9d9a0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe001de9dab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de9dab0 > --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b5c5aa, rsp = 0x7fffffff6ae8, rbp = 0x7fffffffeb50 --- > > > The following is more OpenCrypto or aesni related, but as IPsec is a > consumer, they are related. > > It also looks like OpenCrypto session management wasn't on anyone's > list, partly because the docs for it aren't very good, and until > AES-NI came along, if you provided an explicit IV, the software stack > would "magicly" work. Now w/ AES-NI, that is no longer the case... > > Currently, the aesni driver only has one FPU context allocated per > session, but IPsec will reuse the same session for different requests > from different threads. This means that you can get panics like: > panic: System call sendto returing with kernel FPU ctx leaked > or: > panic: dummy ctx > > As the same session fpu context will be assigned to different kernel > threads stomping on each other's state. Both transport and tunnel > mode suffer (panics) from this issue. I'm working w/ kib on a > possible solution to this. > > There are other issues, such as all the session management code is > looked up via linked lists... This isn't good for performance... One > of the reasons why this was done was to allow migrating sessions between > capable devices, such that if one was overloaded/busy, you could use > another one that isn't as busy... There are better solutions/patterns > now that weren't used back then that should get us around this issue.. > John-Mark, I'm unsure how I can help, only to say that I've been using ipsec over IPv4 between multiple customer sites (branch to Head Offices) since FreeBSD 4.9, they're now 9.2R. We're using both transport and tunnel modes, and use TCP, UDP, ICMP between devices. I intend to migrate them from 9.2 to 10.1Stable within a fortnight, though we're only using IPv4. We also use strongswan for iphone (IKEv1) and Windows7 (IKEv2) VPN connections, ipsec works ok. All boundary devices and the VPN server use VIA-padlock chips (C7). Kind regards, Dewayne.