From owner-freebsd-security@FreeBSD.ORG Sun Nov 16 06:15:28 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 F292F785; Sun, 16 Nov 2014 06:15:27 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3E84D8D; Sun, 16 Nov 2014 06:15:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAG6FQde008545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2014 22:15:26 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAG6FPpp008544; Sat, 15 Nov 2014 22:15:25 -0800 (PST) (envelope-from jmg) Date: Sat, 15 Nov 2014 22:15:25 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141116061525.GG24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-security@freebsd.org, current@freebsd.org References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546744B6.8040504@yandex.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 15 Nov 2014 22:15:26 -0800 (PST) Cc: freebsd-security@freebsd.org, current@freebsd.org 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: Sun, 16 Nov 2014 06:15:28 -0000 Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300: > On 15.11.2014 05:42, John-Mark Gurney wrote: > > I just verified that this happens on a clean HEAD @ r274534: > > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 > > > > No modifications, nothing, and I got the same panic: > > panic: System call sendto returing with kernel FPU ctx leaked > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 > > vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 > > kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 > > amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 > > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = 0x7ffffffee5c0 --- > > KDB: enter: panic > > > > So, it's clearly not my patch that is causing the issue... > > > > Andrey, can you verify that you do not receive the same panic w/o my > > patches? > > I tried 11.0-CURRENT r274549 with and without patches. > Without patches all works as expected. System encrypts and forwards > traffic with and without aesni module. > > With patches software rijndaelEncrypt also works. But when I load > aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors > counter starts grow. And I see messages about wrong source route > attempts from random addresses. Ok, I was able to reproduce the bug, and found that my optimization for single mbuf packets was broken... I've attached a new patch that has the fix... This patch also has added a lock around the aesni fpu context setting to deal w/ the issue that I had... Let me know how things are w/ this new patch. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Sun Nov 16 06:20:20 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 3ADA4B88; Sun, 16 Nov 2014 06:20:20 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 11BE4E0F; Sun, 16 Nov 2014 06:20:19 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAG6KJNZ008611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2014 22:20:19 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAG6KJHt008610; Sat, 15 Nov 2014 22:20:19 -0800 (PST) (envelope-from jmg) Date: Sat, 15 Nov 2014 22:20:18 -0800 From: John-Mark Gurney To: Adrian Chadd Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141116062018.GH24601@funkthat.com> Mail-Followup-To: Adrian Chadd , "Andrey V. Elsukov" , freebsd-security@freebsd.org, "current@freebsd.org" References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> <20141116061525.GG24601@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 15 Nov 2014 22:20:19 -0800 (PST) Cc: freebsd-security@freebsd.org, "Andrey V. Elsukov" , "current@freebsd.org" 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: Sun, 16 Nov 2014 06:20:20 -0000 Adrian Chadd wrote this message on Sat, Nov 15, 2014 at 22:18 -0800: > ... no attachment? Thanks, I put it on the website since I realized it was 155k and a bit large to attach... it's at: https://www.funkthat.com/~jmg/patches/aes.ipsec.6.patch > On 15 November 2014 22:15, John-Mark Gurney wrote: > > Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300: > >> On 15.11.2014 05:42, John-Mark Gurney wrote: > >> > I just verified that this happens on a clean HEAD @ r274534: > >> > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > >> > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 > >> > > >> > No modifications, nothing, and I got the same panic: > >> > panic: System call sendto returing with kernel FPU ctx leaked > >> > cpuid = 0 > >> > KDB: stack backtrace: > >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 > >> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 > >> > vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 > >> > kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 > >> > amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 > >> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 > >> > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = 0x7ffffffee5c0 --- > >> > KDB: enter: panic > >> > > >> > So, it's clearly not my patch that is causing the issue... > >> > > >> > Andrey, can you verify that you do not receive the same panic w/o my > >> > patches? > >> > >> I tried 11.0-CURRENT r274549 with and without patches. > >> Without patches all works as expected. System encrypts and forwards > >> traffic with and without aesni module. > >> > >> With patches software rijndaelEncrypt also works. But when I load > >> aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors > >> counter starts grow. And I see messages about wrong source route > >> attempts from random addresses. > > > > Ok, I was able to reproduce the bug, and found that my optimization > > for single mbuf packets was broken... I've attached a new patch > > that has the fix... > > > > This patch also has added a lock around the aesni fpu context setting > > to deal w/ the issue that I had... > > > > Let me know how things are w/ this new patch. > > > > Thanks. > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Sun Nov 16 06:18:35 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7382A7B; Sun, 16 Nov 2014 06:18:35 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C1E3E02; Sun, 16 Nov 2014 06:18:35 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id z12so4247188wgg.1 for ; Sat, 15 Nov 2014 22:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=4EylnWg1bafbBrLbinzbxK5TwKJilSUa48ZcBYS5qFU=; b=fqvgQXhG2QoMckqV7bjNWahu3cVyBP5NLoaYHUD2CokVCVjsU2rZMukRFu/xdJPD6n VEwc+x8pB36y1GI9zwG+sM9OMQCtoaIDJR/LDMGDg2/1FexITMa3nxZ9QtJ5UStuTVyS +DtZu36Npnbn93LvN0iRgmb94JBtJsI8zMaL842dMgN0zrrLrvpWhyQ2sJu9vsXYmlvF uguW3OAQ8u/GZws+pLfoyczfTCOewcEUllFCpPmvU0rryj7K3fa47tTuoGTo0PZIlHXp fnkV5qgcJsqYLhz59brVe2+xjabPPhSb4Q3KgzpymGYCQxldLmZsmtNoFX9r7ETPZSqv 0s5Q== MIME-Version: 1.0 X-Received: by 10.180.83.98 with SMTP id p2mr21169288wiy.20.1416118713818; Sat, 15 Nov 2014 22:18:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 15 Nov 2014 22:18:32 -0800 (PST) In-Reply-To: <20141116061525.GG24601@funkthat.com> References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> <20141116061525.GG24601@funkthat.com> Date: Sat, 15 Nov 2014 22:18:32 -0800 X-Google-Sender-Auth: 52YUPCelGkWABckxG2XJNLQqXuY Message-ID: Subject: Re: CFR: AES-GCM and OpenCrypto work review From: Adrian Chadd To: "Andrey V. Elsukov" , freebsd-security@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 16 Nov 2014 12:32:04 +0000 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: Sun, 16 Nov 2014 06:18:35 -0000 ... no attachment? -adrian On 15 November 2014 22:15, John-Mark Gurney wrote: > Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300: >> On 15.11.2014 05:42, John-Mark Gurney wrote: >> > I just verified that this happens on a clean HEAD @ r274534: >> > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 >> > jmg@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 >> > >> > No modifications, nothing, and I got the same panic: >> > panic: System call sendto returing with kernel FPU ctx leaked >> > cpuid = 0 >> > KDB: stack backtrace: >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 >> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 >> > vpanic() at vpanic+0x189/frame 0xfffffe001de7a930 >> > kassert_panic() at kassert_panic+0x139/frame 0xfffffe001de7a9a0 >> > amd64_syscall() at amd64_syscall+0x616/frame 0xfffffe001de7aab0 >> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 >> > --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = 0x7ffffffee5c0 --- >> > KDB: enter: panic >> > >> > So, it's clearly not my patch that is causing the issue... >> > >> > Andrey, can you verify that you do not receive the same panic w/o my >> > patches? >> >> I tried 11.0-CURRENT r274549 with and without patches. >> Without patches all works as expected. System encrypts and forwards >> traffic with and without aesni module. >> >> With patches software rijndaelEncrypt also works. But when I load >> aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors >> counter starts grow. And I see messages about wrong source route >> attempts from random addresses. > > Ok, I was able to reproduce the bug, and found that my optimization > for single mbuf packets was broken... I've attached a new patch > that has the fix... > > This patch also has added a lock around the aesni fpu context setting > to deal w/ the issue that I had... > > Let me know how things are w/ this new patch. > > Thanks. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Mon Nov 17 02:48:23 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 02986F6A; Mon, 17 Nov 2014 02:48:23 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 977A7D14; Mon, 17 Nov 2014 02:48:22 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) by dyslexicfish.net (8.14.5/8.14.5) with ESMTP id sAH2cLdt062440; Mon, 17 Nov 2014 02:38:21 GMT (envelope-from jamie@dyslexicfish.net) Received: (from jamie@localhost) by dyslexicfish.net (8.14.5/8.14.5/Submit) id sAH2cLXQ062439; Mon, 17 Nov 2014 02:38:21 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201411170238.sAH2cLXQ062439@dyslexicfish.net> Date: Mon, 17 Nov 2014 02:38:21 +0000 To: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Potential security issues with new top level domains? User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (dyslexicfish.net [91.109.5.35]); Mon, 17 Nov 2014 02:38:21 +0000 (GMT) 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: Mon, 17 Nov 2014 02:48:23 -0000 As if I needed another reason to hate the new top level domain free-for-all, I was checking on one of my machines earlier, and forgot that I'd renamed it, so it is no longer in my domains DNS. This was the result: | 2:13 (2) "~" jamie@catflap% ping android | PING android (127.0.53.53): 56 data bytes | ping: sendto: Can't assign requested address | ping: sendto: Can't assign requested address | ping: sendto: Can't assign requested address | ^C | --- android ping statistics --- | 3 packets transmitted, 0 packets received, 100.0% packet loss | | 2:13 (3) "~" jamie@catflap% cat /etc/resolv.conf | domain dyslexicfish.net | nameserver 127.0.0.1 | options edns0 A quick check revealed that, as expected, unbound was first asked for 'android.dyslexicfish.net.' which returned NX, and was then asked for 'android.' which resolved the 'A' that the owners of the TLD have configured. Now, any scripts/binaries etc. I have that use DNS resolution always use the FQDN with the trailing dot, so I have no personal security worries, but I'm sure there are others out there that don't, and even so, it could still bite for interactive use. Yes, the 'A' returned is invalid in this case, but what's to say this will be the case with all future new TLDs? I realise the spec is being followed correctly, but it still seems wrong to me that any 'host' related resource types resolve for an address at the top level, and I was wondering what others thought about it? Should the FreeBSD resolver ignore / not make such requests? Should instead the functionality be built into unbound/named etc.? Should instead TLD owners be banned from adding such records? (this still could be abused though) Should neither be done? I dunno, I'm just used to A/AAAA resolves on a non qualified address to either come from /etc/hosts, or be in under a domain in 'domain/search' from /etc/resolv.conf The current situation seems 'wrong' and potentially troublesome to me, but I'd be interested in what others think. Cheers, Jamie From owner-freebsd-security@FreeBSD.ORG Mon Nov 17 03:18:39 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C8D7C04; Mon, 17 Nov 2014 03:18:39 +0000 (UTC) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73970DE; Mon, 17 Nov 2014 03:18:38 +0000 (UTC) Received: from [10.20.30.90] (142-254-17-111.dsl.dynamic.fusionbroadband.com [142.254.17.111]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sAH3INNB056185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Nov 2014 20:18:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-111.dsl.dynamic.fusionbroadband.com [142.254.17.111] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Potential security issues with new top level domains? From: Paul Hoffman In-Reply-To: <201411170238.sAH2cLXQ062439@dyslexicfish.net> Date: Sun, 16 Nov 2014 19:18:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9848F63A-D88F-4A8A-A15B-E2B5D4A5939C@vpnc.org> References: <201411170238.sAH2cLXQ062439@dyslexicfish.net> To: Jamie Landeg-Jones X-Mailer: Apple Mail (2.1990.1) X-Mailman-Approved-At: Mon, 17 Nov 2014 03:21:19 +0000 Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org 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: Mon, 17 Nov 2014 03:18:39 -0000 On Nov 16, 2014, at 6:38 PM, Jamie Landeg-Jones = wrote: > Yes, the 'A' returned is invalid in this case, but what's to say this > will be the case with all future new TLDs? It will be the case for the first 90 days for all new TLDs that have = three or more letters in their names; it will probably not be true for = new TLDs with two letters in their name. > I realise the spec is being followed correctly, Yes. > but it still seems wrong > to me that any 'host' related resource types resolve for an address at = the > top level, and I was wondering what others thought about it? The spec is being followed correctly, and there are many other TLDs that = do this: see . > Should the FreeBSD resolver ignore / not make such requests? >=20 > Should instead the functionality be built into unbound/named etc.? >=20 > Should instead TLD owners be banned from adding such records? (this = still > could be abused though) No, no, and no. As you say above, the spec is being followed. You can = mitigate your misuse of the DNS: = . --Paul Hoffman (a long-time FreeBSDer who co-wrote the above RFC, and also wrote the = ICANN report)= From owner-freebsd-security@FreeBSD.ORG Mon Nov 17 18:35:21 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 44F19C2; Mon, 17 Nov 2014 18:35:21 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECD05106; Mon, 17 Nov 2014 18:35:20 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward5l.mail.yandex.net (Yandex) with ESMTP id 94CAEC414E2; Mon, 17 Nov 2014 21:35:17 +0300 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 1AC961340C58; Mon, 17 Nov 2014 21:35:16 +0300 (MSK) Received: from 84.201.165.9-vpn.dhcp.yndx.net (84.201.165.9-vpn.dhcp.yndx.net [84.201.165.9]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id PScP7wSFpY-ZGg8wAEq; Mon, 17 Nov 2014 21:35:16 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 4ff82e88-1b38-4d30-8086-60161f4d1e46 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1416249316; bh=o9q5beg9yQiuUwD48mieZ/qc3d2K9eCDkLFhglmf7cc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=F1ipfvdYE+DrYaZ6kww5z9oJqE1hS6A5g/yHQ5BWCrMnh7Sa88e2BPjltPD97S2yO 9iRRl3vDte88qVyNHH6jGUb0lk5105VqG9X/sBGnlkVF/QyF8w5alfTJUT5SmJAfPv K5qKSYjJTU3zu8RG33Qn7g50WqGtLLPj0hvqnvrc= Authentication-Results: smtp1h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <546A3FB8.8080808@yandex.ru> Date: Mon, 17 Nov 2014 21:34:32 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org, current@freebsd.org Subject: Re: CFR: AES-GCM and OpenCrypto work review References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> <20141116061525.GG24601@funkthat.com> In-Reply-To: <20141116061525.GG24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xk5GosCE5S4w41ADP5rTJVQD7GArp2Tev" 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: Mon, 17 Nov 2014 18:35:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xk5GosCE5S4w41ADP5rTJVQD7GArp2Tev Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 16.11.2014 09:15, John-Mark Gurney wrote: > Ok, I was able to reproduce the bug, and found that my optimization > for single mbuf packets was broken... I've attached a new patch > that has the fix... >=20 > This patch also has added a lock around the aesni fpu context setting > to deal w/ the issue that I had... >=20 > Let me know how things are w/ this new patch. Hi, with this patch all works as expected. --=20 WBR, Andrey V. Elsukov --xk5GosCE5S4w41ADP5rTJVQD7GArp2Tev Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUaj+/AAoJEAHF6gQQyKF6wD8H/RwpnNmiwCxKbApaNobGzvwX eVW4QvcSMvnJjdj67LHmf0yGv4GRf1tizk4XIvQk/Ca+AFwJULjASbSPpgPI6hW7 +WPSv/bsVmilSy6QIlOl25/BYDDAK0/w2nYdDplBh6Lb41fiv7i2BKtioQIW3QBk AIaXPz981Nw1JfpVX+nDxfIOxI2/x3KN2UrJuER/QXogZLICZNtqUONb0X4NUzfu GOUNazHReIwt31a61DZpx7gfhe5Up3NM9MXkkioJvEV3XYSMnE9L32LA19NOEXld kLX7TRqkWP12TtrXtAblzqyZmKgbWTGctaPU6boJDtkiBm8MJ1Boe68wHoMToHo= =1RaY -----END PGP SIGNATURE----- --xk5GosCE5S4w41ADP5rTJVQD7GArp2Tev-- From owner-freebsd-security@FreeBSD.ORG Mon Nov 17 20:31:17 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD9B233B; Mon, 17 Nov 2014 20:31:17 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C9F7FF; Mon, 17 Nov 2014 20:31:16 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAHKVE3f035398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2014 12:31:15 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAHKVEJ2035397; Mon, 17 Nov 2014 12:31:14 -0800 (PST) (envelope-from jmg) Date: Mon, 17 Nov 2014 12:31:14 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: CFR: AES-GCM and OpenCrypto work review Message-ID: <20141117203114.GQ24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-security@freebsd.org, current@freebsd.org References: <20141108042300.GA24601@funkthat.com> <54655257.8080705@yandex.ru> <54660389.9060409@yandex.ru> <20141114193911.GR24601@funkthat.com> <20141115024201.GW24601@funkthat.com> <546744B6.8040504@yandex.ru> <20141116061525.GG24601@funkthat.com> <546A3FB8.8080808@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546A3FB8.8080808@yandex.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 17 Nov 2014 12:31:15 -0800 (PST) Cc: freebsd-security@freebsd.org, current@freebsd.org 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: Mon, 17 Nov 2014 20:31:17 -0000 Andrey V. Elsukov wrote this message on Mon, Nov 17, 2014 at 21:34 +0300: > On 16.11.2014 09:15, John-Mark Gurney wrote: > > Ok, I was able to reproduce the bug, and found that my optimization > > for single mbuf packets was broken... I've attached a new patch > > that has the fix... > > > > This patch also has added a lock around the aesni fpu context setting > > to deal w/ the issue that I had... > > > > Let me know how things are w/ this new patch. > > with this patch all works as expected. Just so you know, even tunnel mode w/ aesni on a clean HEAD can panic.. I just got a: panic: dummy ctx from the tunnel mode by having two machines ping -f'ing each other... This is a different form of the same panic I posted about earlier w/ the fpu context being reused for different threads... I plan on committing the patch w/o the mtx_lock as including the lock will significantly impact people who use geli... I am working on a fix for this w/ kib that will allow us to not allocate an fpu context and get things a little more stable, but there are other bugs that also need to be addressed before aesni is safe to use w/ IPsec... Thanks for testing! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Thu Nov 20 21:35:33 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 B1F74433; Thu, 20 Nov 2014 21:35:33 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 923ACF9D; Thu, 20 Nov 2014 21:35:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAKLZQGr098565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 13:35:27 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAKLZQk2098564; Thu, 20 Nov 2014 13:35:26 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Nov 2014 13:35:26 -0800 From: John-Mark Gurney To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Subject: IPsec is very broken... Message-ID: <20141120213526.GH24601@funkthat.com> Mail-Followup-To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 20 Nov 2014 13:35:27 -0800 (PST) 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 21:35:33 -0000 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 Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Thu Nov 20 22:38: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 E7132AA7; Thu, 20 Nov 2014 22:38:18 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E37F945; Thu, 20 Nov 2014 22:38:18 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAKMcHOu099333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 14:38:17 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAKMcHce099332; Thu, 20 Nov 2014 14:38:17 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Nov 2014 14:38:17 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Subject: Re: IPsec is very broken... Message-ID: <20141120223816.GJ24601@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , freebsd-net@freebsd.org, freebsd-security@freebsd.org References: <20141120213526.GH24601@funkthat.com> <546E6931.20406@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546E6931.20406@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 20 Nov 2014 14:38:17 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-security@freebsd.org 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:38:19 -0000 Andrey V. Elsukov wrote this message on Fri, Nov 21, 2014 at 01:20 +0300: > On 21.11.2014 00:35, 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. > > I usually do tests for both transport and tunnel modes with and without > gif(4)/gre(4). So, just tried between two CURRENT hosts and it works. > I use racoon and isakmpd for IKE. ICMP, TCP (ssh) and UDP (ike) works > for me. How do you test? Do you use software crypto or aesni? Hmm... weird... Just tested again and TCP seems to be working now... Not sure what changed... It could be that I didn't retest after fixing AES-NI's mbuf issue, but I thought I had... Though I thought I had tested a clean HEAD too... I've only been testing w/ static associations to make testing easier.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." 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. From owner-freebsd-security@FreeBSD.ORG Thu Nov 20 22:21:13 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AA475D9; Thu, 20 Nov 2014 22:21:13 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id C16AC1F7A; Thu, 20 Nov 2014 22:21:12 +0000 (UTC) Message-ID: <546E6931.20406@FreeBSD.org> Date: Fri, 21 Nov 2014 01:20:33 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Subject: Re: IPsec is very broken... References: <20141120213526.GH24601@funkthat.com> In-Reply-To: <20141120213526.GH24601@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="09FKR9v2hpJiJmT7vEP5u19xTMXe8to3d" X-Mailman-Approved-At: Thu, 20 Nov 2014 23:43:48 +0000 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:21:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --09FKR9v2hpJiJmT7vEP5u19xTMXe8to3d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 21.11.2014 00:35, 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. >=20 > 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... >=20 > 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. I usually do tests for both transport and tunnel modes with and without gif(4)/gre(4). So, just tried between two CURRENT hosts and it works. I use racoon and isakmpd for IKE. ICMP, TCP (ssh) and UDP (ike) works for me. How do you test? Do you use software crypto or aesni? --=20 WBR, Andrey V. Elsukov --09FKR9v2hpJiJmT7vEP5u19xTMXe8to3d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUbmk1AAoJEAHF6gQQyKF6lhQIALjov+pssuB8eYB3YTCIo02q RN9OzxW4nwbbEs82q3UqAxRR+oZlgEwDkVvORieJeWguBA0uhaILegiQGnG4WhXD TTITHC0upzoSKJ/mcEglCmBZcBTZX4CQ9lgSrNShgRwHPlrihmARz3PlxtswtXqE zioNtUaKAcC0aBRDiMbAK1/ODgoJvp4GCfKYlhkUxsoG3GiGM2uxstHXSzPh8hwZ ev4K0YmVgPUdB0orlQ6GpYIii3nclllNyi7hHnYqfkMupsDJ2EqH8WYYOMvUAhuy eInkcULgx67euruZ+enxtMlf2PxmZFVOxTDS+vfqqRdLN8tZE1/BYa+zhvviRb0= =x6EG -----END PGP SIGNATURE----- --09FKR9v2hpJiJmT7vEP5u19xTMXe8to3d-- From owner-freebsd-security@FreeBSD.ORG Fri Nov 21 11:28:06 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 1B266B33; Fri, 21 Nov 2014 11:28:06 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C7D40ED; Fri, 21 Nov 2014 11:28:05 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C55FB25D3892; Fri, 21 Nov 2014 11:28:02 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 02184C76FE0; Fri, 21 Nov 2014 11:28:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id oS7gXTuralSA; Fri, 21 Nov 2014 11:28:00 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D3303C76FD9; Fri, 21 Nov 2014 11:27:59 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: IPsec is very broken... From: "Bjoern A. Zeeb" In-Reply-To: <20141120213526.GH24601@funkthat.com> Date: Fri, 21 Nov 2014 11:27:57 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <785031F3-7563-4314-A9A5-79666723C3E2@lists.zabbadoz.net> References: <20141120213526.GH24601@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org 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: Fri, 21 Nov 2014 11:28:06 -0000 On 20 Nov 2014, at 21:35 , John-Mark Gurney wrote: > 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=85 Or that some people lately broke the code. > 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. + SCTP + IPcomp + IPv4/IPv6 mixes inside/outside + properly working = enc(4) If you get all that then add IPIP (gif) and GRE on the inside as well. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983