From owner-freebsd-security@freebsd.org Mon Oct 16 11:56:19 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 75355E37F8D; Mon, 16 Oct 2017 11:56:19 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3AEBB7D30C; Mon, 16 Oct 2017 11:56:19 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 80018A6B; Mon, 16 Oct 2017 14:56:17 +0300 (MSK) To: freebsd-security , freebsd-wireless Reply-To: lev@FreeBSD.org From: Lev Serebryakov Subject: =?UTF-8?Q?WPA2_vulnerabilities_=e2=80=94_is_FreeBSD-as-AP_affected?= =?UTF-8?Q?=3f?= Organization: FreeBSD Message-ID: <3bcef903-4d27-b49f-81aa-9e055e22efa5@FreeBSD.org> Date: Mon, 16 Oct 2017 14:56:08 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wDVabAT7U1AH8f66Tatx4BlhKi3ws0KsS" 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: Mon, 16 Oct 2017 11:56:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wDVabAT7U1AH8f66Tatx4BlhKi3ws0KsS Content-Type: multipart/mixed; boundary="WJAspIE6aNJWHLWocJRKofqW4MqGJm3Gh"; protected-headers="v1" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: freebsd-security , freebsd-wireless Message-ID: <3bcef903-4d27-b49f-81aa-9e055e22efa5@FreeBSD.org> Subject: =?UTF-8?Q?WPA2_vulnerabilities_=e2=80=94_is_FreeBSD-as-AP_affected?= =?UTF-8?Q?=3f?= --WJAspIE6aNJWHLWocJRKofqW4MqGJm3Gh Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable There are whole lot of new vulnerabilities in WPA2 [implementations?]: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088. Does anybody know, is FreeBSD (our WiFi stack + hostapd / wpa_supplicant) affected? --=20 // Lev Serebryakov --WJAspIE6aNJWHLWocJRKofqW4MqGJm3Gh-- --wDVabAT7U1AH8f66Tatx4BlhKi3ws0KsS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJZ5J5fXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePlwMP/1Ko+dNF9CHmgJhtZ48EjbPk WO9S9cuI4+T2fB9DgmVvWovmYhwoi+msp4dudUU09PrzC/PdrrdTGtwBZ+wF4vbO TuaO+B5HLCjKt2QIvsZSxifaQ+yox8zu6dOuUAzdy0rw/DydbqtY7CLLiDQhkpWr YSMkIYv9BY/MrjIsLKKpxMCw0jsC2qbA9E9R9mHCdLN+IxtQXWGQ786OYfqDJE9B CQVY1CY7gZ3aUPFOhM7ZB2uKFSkeR83oxDLT00ha8sdrAR1joPzEl4+tAWyHYIz6 KnpRuODOLekfIIkVOEIxby3DdR/WIiVjE4HQtt4dVI3i2h2y3O7eo/NaMCYODW2J WQUS3KQLCoOX/vxvm0yEWdBT5ZwmeJ5CmuWyZc//10p0wyv5JjONYwmxGbiclcgy sbW42BxkNqcEiy7pg3zpx0IThZNjtly93TEQT5Dht0lG2RDju0PaIEAGz2f3N1MH wF6N2j5lAUy4l0Alw4v+uy2ZX22mXTnXfX7OzwPXtQzdMXpx9A+UTOVWy3sObtNf KpTBFOwb8/mh6mPryAYwve5zVQ5IGCXARvRQCFsnvZOuREXDzW2F/qU7JmPzhsoZ efu6SlK6T5cyR7ovBrAHeDjkJRW5bfMpn71vGvzbh+xoYD+hOVwReCMmWcmqf/j6 bJzwBrR21WeSc6b4wPck =u62x -----END PGP SIGNATURE----- --wDVabAT7U1AH8f66Tatx4BlhKi3ws0KsS-- From owner-freebsd-security@freebsd.org Mon Oct 16 12:03:58 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 838F2E38B8E; Mon, 16 Oct 2017 12:03:58 +0000 (UTC) (envelope-from SRS0=qApe=BP=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 41FB67DB52; Mon, 16 Oct 2017 12:03:57 +0000 (UTC) (envelope-from SRS0=qApe=BP=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 2A1C728416; Mon, 16 Oct 2017 14:03:49 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 4F56128411; Mon, 16 Oct 2017 14:03:48 +0200 (CEST) Subject: =?UTF-8?Q?Re:_WPA2_vulnerabilities_=e2=80=94_is_FreeBSD-as-AP_affec?= =?UTF-8?Q?ted=3f?= To: lev@FreeBSD.org, freebsd-security , freebsd-wireless References: <3bcef903-4d27-b49f-81aa-9e055e22efa5@FreeBSD.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <59E4A024.6070708@quip.cz> Date: Mon, 16 Oct 2017 14:03:48 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <3bcef903-4d27-b49f-81aa-9e055e22efa5@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 16 Oct 2017 12:03:58 -0000 Lev Serebryakov wrote on 10/16/2017 13:56: > > There are whole lot of new vulnerabilities in WPA2 [implementations?]: > CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, > CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, > CVE-2017-13087, CVE-2017-13088. > > Does anybody know, is FreeBSD (our WiFi stack + hostapd / > wpa_supplicant) affected? Yes. it is discussed at current@ with patch https://lists.freebsd.org/pipermail/freebsd-current/2017-October/067193.html Miroslav Lachman From owner-freebsd-security@freebsd.org Mon Oct 16 15:36:47 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 119ADE3D469; Mon, 16 Oct 2017 15:36:47 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [IPv6:2a01:4f8:a0:51d7::103:2]) (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 CCE4284EC5; Mon, 16 Oct 2017 15:36:46 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from [IPv6:2a02:8106:22a:4b02:a42b:20d9:659f:eccd] (unknown [IPv6:2a02:8106:22a:4b02:a42b:20d9:659f:eccd]) by host64.shmhost.net (Postfix) with ESMTPSA id 07560162A01; Mon, 16 Oct 2017 17:36:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_WPA2_vulnerabilities_=E2=80=94_is_FreeBSD-as-AP_a?= =?utf-8?Q?ffected=3F?= From: Franco Fichtner In-Reply-To: <59E4A024.6070708@quip.cz> Date: Mon, 16 Oct 2017 17:36:31 +0200 Cc: lev@FreeBSD.org, freebsd-security , freebsd-wireless Content-Transfer-Encoding: quoted-printable Message-Id: References: <3bcef903-4d27-b49f-81aa-9e055e22efa5@FreeBSD.org> <59E4A024.6070708@quip.cz> To: Miroslav Lachman <000.fbsd@quip.cz> X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at host64.shmhost.net X-Virus-Status: Clean X-Spam-Flag: NO X-Spam-Score: -1.0 X-Spam-Status: No score=-1.0 tagged_above=10.0 required=10.0 tests=[ALL_TRUSTED] 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: Mon, 16 Oct 2017 15:36:47 -0000 > On 16. Oct 2017, at 2:03 PM, Miroslav Lachman <000.fbsd@quip.cz> = wrote: >=20 > Lev Serebryakov wrote on 10/16/2017 13:56: >>=20 >> There are whole lot of new vulnerabilities in WPA2 = [implementations?]: >> CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, >> CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, >> CVE-2017-13087, CVE-2017-13088. >>=20 >> Does anybody know, is FreeBSD (our WiFi stack + hostapd / >> wpa_supplicant) affected? >=20 > Yes. it is discussed at current@ with patch > = https://lists.freebsd.org/pipermail/freebsd-current/2017-October/067193.ht= ml Did CERT/CC while extending the deadline forget to inform FreeBSD if it was not informed already? I am not sure why patches are thrown around on a mailing list after such an extensive embargo period. Cheers, Franco= From owner-freebsd-security@freebsd.org Mon Oct 16 22:13:58 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 5AEFDE46B19 for ; Mon, 16 Oct 2017 22:13:58 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id E6B326FB0C for ; Mon, 16 Oct 2017 22:13:56 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 3FF8D3AF00 for ; Mon, 16 Oct 2017 15:13:50 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: WPA2 bugz - One Man's Quick & Dirty Response Date: Mon, 16 Oct 2017 15:13:49 -0700 Message-ID: <25911.1508192029@segfault.tristatelogic.com> 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: Mon, 16 Oct 2017 22:13:58 -0000 Just like everybody else on this list, I guess, I'm rather less than happy about the WPA2 story that has emerged within the past 24 hours. Due to the announcement that WPA2 is, apparently, badly broken, I'm trying now to figure out how to lock down my home network a little better... as, I suspect, are many others all over the world... at least until the equipment vendors get around to issuing firmware patches. Up untill last night, when I read the WPA2 news, I just blindly trusted everything on my local network, with the result being that I've got and /etc/exports file, and also its Samba equivalent, that are making each of the several top-level directories that hold most of the stuff on my central FreeBSD "file server" machine available, without restriction, to the local subnet as follows: #/etc/exports /home/mini-me -alldirs -network 192.168.1.0 -mask 255.255.255.0 /one -alldirs -network 192.168.1.0 -mask 255.255.255.0 /two -alldirs -network 192.168.1.0 -mask 255.255.255.0 /three -alldirs -network 192.168.1.0 -mask 255.255.255.0 (There's basically equivalent stuff also in my Samba config files.) In light of the recent WPA2 disclosures, it has occured to me that as of today it may be a Bad Idea for me to be exporting all of this stuff, read/write, to all of 192.168.1.0/24. I'm fortunate, because I just have a simple little home network, and there are only, at most, a handful of devices on it. I've already taken the step of (re-)configuring all of my hardwired devices so that they are all using static IPs within just the 192.168.1.16/28 sub-block. These machines... my hardwired ones... are the ones I intend to continue to trust completely. They will continue to have read/write access to all of the directories mentioned above. I've also just diddled my router config so as to have it issue local IP addresses to DHCP clients within just the 192.168.192.0/26 range. This is going to be a range that I only trust marginally from now on, i.e. just enough to have read-only access to -just- my content directories /one, /two, and /three. Basically, I'm just arranging things so that all my hardwired stuff is on static IPs, within a limited little subnet, and all of my WiFi stuff will continue to do DHCP, also within a limited, but different subnet. So, based on all of the foregoing, my new /etc/exports file will look something like this: # trusted /home/mini-me -alldirs -network 192.168.1.16 -mask 255.255.255.240 /one -alldirs -network 192.168.1.16 -mask 255.255.255.240 /two -alldirs -network 192.168.1.16 -mask 255.255.255.240 /three -alldirs -network 192.168.1.16 -mask 255.255.255.240 # semi-trusted /one -ro -alldirs -network 192.168.1.192 -mask 255.255.255.192 /two -ro -alldirs -network 192.168.1.192 -mask 255.255.255.192 /three -ro -alldirs -network 192.168.1.192 -mask 255.255.255.192 ... and I'll make similar adjustments also in my Samba config files. Well, anyway, this is my plan at the moment. I'd be happy to have any critiques or helpful suggestions. Of course, none of this is optimal... not like having real working WiFi security would be. But in my specific case, if somebody manages to get in and fiddle, in arbitrary ways, with the communications between my WiFi devices... which mostly consist of just "home theater" type stuff in the living room... then it will be no biggie, just as long as whoever is doing it will, at worst, just have read-only access to my content files. I can live with that, I think, at least until the firmware cavalry arrives. Regards, rfg From owner-freebsd-security@freebsd.org Mon Oct 16 23:19:41 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 74C3AE48234 for ; Mon, 16 Oct 2017 23:19:41 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5309271A6A for ; Mon, 16 Oct 2017 23:19:40 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id v9GN5PMP026332 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Oct 2017 16:05:25 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id v9GN5Pj5026331; Mon, 16 Oct 2017 16:05:25 -0700 (PDT) (envelope-from jmg) Date: Mon, 16 Oct 2017 16:05:25 -0700 From: John-Mark Gurney To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response Message-ID: <20171016230525.GA94181@funkthat.com> Mail-Followup-To: "Ronald F. Guilmette" , freebsd-security@freebsd.org References: <25911.1508192029@segfault.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25911.1508192029@segfault.tristatelogic.com> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 16 Oct 2017 16:05:25 -0700 (PDT) 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: Mon, 16 Oct 2017 23:19:41 -0000 Ronald F. Guilmette wrote this message on Mon, Oct 16, 2017 at 15:13 -0700: > Just like everybody else on this list, I guess, I'm rather less than > happy about the WPA2 story that has emerged within the past 24 hours. > > Due to the announcement that WPA2 is, apparently, badly broken, I'm > trying now to figure out how to lock down my home network a little > better... as, I suspect, are many others all over the world... at > least until the equipment vendors get around to issuing firmware patches. > > Up untill last night, when I read the WPA2 news, I just blindly trusted > everything on my local network, with the result being that I've got > and /etc/exports file, and also its Samba equivalent, that are making > each of the several top-level directories that hold most of the stuff > on my central FreeBSD "file server" machine available, without restriction, > to the local subnet as follows: > > #/etc/exports > /home/mini-me -alldirs -network 192.168.1.0 -mask 255.255.255.0 > /one -alldirs -network 192.168.1.0 -mask 255.255.255.0 > /two -alldirs -network 192.168.1.0 -mask 255.255.255.0 > /three -alldirs -network 192.168.1.0 -mask 255.255.255.0 > > (There's basically equivalent stuff also in my Samba config files.) > > In light of the recent WPA2 disclosures, it has occured to me that > as of today it may be a Bad Idea for me to be exporting all of this > stuff, read/write, to all of 192.168.1.0/24. Doesn't matter, if your network is compromized, only strong encryption and authentication will save you.. For this you need NFSv4+kerberos, SMBv3 (which I have no clue how to ensure things are auth/enc'd) or WebDAV over https for file sharing. Restricting what hosts doesn't solve the problem. Also, w/ your config, you have to make sure your router does ingress filtering, as many times you can spoof packets between subnets too... > Of course, none of this is optimal... not like having real working > WiFi security would be. But in my specific case, if somebody manages > to get in and fiddle, in arbitrary ways, with the communications between > my WiFi devices... which mostly consist of just "home theater" type > stuff in the living room... then it will be no biggie, just as long as > whoever is doing it will, at worst, just have read-only access to my > content files. Best way to assume is that the network is always compromized, and that it's up to the nodes to protect the data... -- 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 Tue Oct 17 02:14:28 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 D24D0E4EC7A for ; Tue, 17 Oct 2017 02:14:28 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id AFC0E7C52C for ; Tue, 17 Oct 2017 02:14:27 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id D69D43ACDA for ; Mon, 16 Oct 2017 19:14:26 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response In-Reply-To: <20171016230525.GA94181@funkthat.com> Date: Mon, 16 Oct 2017 19:14:26 -0700 Message-ID: <27180.1508206466@segfault.tristatelogic.com> 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: Tue, 17 Oct 2017 02:14:28 -0000 In message <20171016230525.GA94181@funkthat.com>, John-Mark Gurney wrote: >> In light of the recent WPA2 disclosures, it has occured to me that >> as of today it may be a Bad Idea for me to be exporting all of this >> stuff, read/write, to all of 192.168.1.0/24. > >Doesn't matter, if your network is compromized, only strong encryption >and authentication will save you.. Hummm... I *think* that maybe I'm starting to understand now. But maybe not. I'm at a bit of a disadvantage, because like 99.999% of the population I'm still not entirely 100% clear on what can and can't be done with these new WPA2 exploits. But the thought did just occur to me... based on your comment... that these WPA2 problems might possibly be leveragable to the point where an attacker could be talking to my router via WiFi -and- could be doing so while using an IP address within the range (192.168.1.16/28) that I had hoped to export some NFS volumes to with read/write access. Is this, in effect, what you were suggesting? Or have I misunderstood yet again? Assuming that I am basically on the Right Track, now, what should I do? What can be done? I am not just asking for me, but also on behalf of the few zillion other poor sods who, like me, know just enough about networking to be dangerous, and who, like me, have been caught rather flat footed by these WPA2 issues. I suspect that I am somewhat typical of a lot of folks. I have a file server system (mine happens to run FreeBSD) in one room (the office) and some clients that need at most read-only access to files on the file server in another room (i.e. the living room) where the connectivity is down with WiFi. I could use Samba/SMB for this, but in my experience NFS provides drastically better performance, so I've used that instead of SMB. In the living room there's an x86-based HTPC running a crusty old version of OpenELEC (and it is this box, specifically, that needs the read-only access to the stuff on my file server) and also there's an Amazon Fire TV box, which has "secure" (giggle) access to some paid content elsewhere on the Internet. Meanwhile, in the office, in addition to the FreeBSD machine which is my main workstation -and- file server, I also have a second machine running Linux/Ubuntu and a third machine running Windoze7. These are both hardwired into my Linksys E4200... a fact which I had hoped to leverage to give me some extra protection from these new WPA2 issues, but now I'm thinking maybe that won't actually fly. (I want these two machines to have read/write access to almost everything on my main file server machine.) Based on your comments, John-Mark, and the earlier and equally worrying comments by Karl Denninger, I'm beginning to think that perhaps the only Right Way to solve all of the issues/problems/requirements that I'm facing is perhaps for me to set up a second local "more trusted" network, e.g. 192.168.2.0/24 and for me to add a simple switch and additional ethernet cards to each of my hardwired machines so that they can all talk to the new switch. Then I can export my NFS volumes, read/write, to 192.168.2.0/24, including even home directories and other exceptionally sensitive stuff, but then also just NFS-export just my content/media volumes read-only to the (now entirely and physically separate) 192.168.1.0/24 network. Is this a Good Plan or a Rotten Plan? As I've already stipulated, I know just enough about networking to be dangerous, so advice would be appreciated. Also, what about the Amazon Fire TV box in the living room? It seems that it contains some magical crypto secrets that allow me to access certain paid content, in preference to others who haven't paid for it. Are all of those secrets now going to be up for grabs to anyone, staring tomorrow, who is physically close enough to connect to my WiFi router and who has his his/her possession appropriate WPA2 exploit code? If so, then what should I do... what -can- I even do about *that*? (Obviously, that is all closed-source proprietary stuff under the hood in that box, which greatly limits my options, and those of untold millions of others.) >Also, w/ your config, you have to make sure your router does ingress >filtering, as many times you can spoof packets between subnets too... Two obvious questions: (1) "How?" and (2) "On which port(s), exactly? All of them?" I frankly don't know enough about -either- my Linksys E4200 -or- the ASUS RT-AC56U that's been sitting on my shelf for awhile now, waiting to replace the Linksys. And I specifically don't have any notion of how I either can or should tweek the filtering to comply with your suggestion, but I am more than wlling to be instructed. Lastly, with respect to SOHO routers generally... Shall I start up a betting pool? It will be interesting to see, in the weeks and months ahead, for each given SOHO WiFi router model, which comes out first, i.e. either (a) vendor-supplied firmware updates that deal with all of these WPA2 issues, or else (b) "WPA2-fix" versions of DD-WRT, OpenWRT, or Tomato for the same model(s). I'm betting that for a lot of these things, the open source firmwares with the WPA2 fixes are going to be out sooner that the equivalent vendor-supplied fixed firmwares. And of course, for a lot of older "orphaned" routers, fixed-up open source firmwares are likely to be the -only- choice, forever. Maybe that's a Good Thing. From owner-freebsd-security@freebsd.org Tue Oct 17 02:35:09 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 63E74E27019 for ; Tue, 17 Oct 2017 02:35:09 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 24FD67D460 for ; Tue, 17 Oct 2017 02:35:08 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 52DE72743C for ; Mon, 16 Oct 2017 22:24:46 -0400 (EDT) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 612A82CAF90 for ; Mon, 16 Oct 2017 21:24:44 -0500 (CDT) Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response To: freebsd-security@freebsd.org References: <27180.1508206466@segfault.tristatelogic.com> From: Karl Denninger Message-ID: Date: Mon, 16 Oct 2017 21:24:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <27180.1508206466@segfault.tristatelogic.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070403050509010908050303" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Tue, 17 Oct 2017 02:35:09 -0000 This is a cryptographically signed message in MIME format. --------------ms070403050509010908050303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/16/2017 21:14, Ronald F. Guilmette wrote: > In message <20171016230525.GA94181@funkthat.com>,=20 > John-Mark Gurney wrote: > >>> In light of the recent WPA2 disclosures, it has occured to me that >>> as of today it may be a Bad Idea for me to be exporting all of this >>> stuff, read/write, to all of 192.168.1.0/24. >> Doesn't matter, if your network is compromized, only strong encryption= >> and authentication will save you.. > Hummm... I *think* that maybe I'm starting to understand now. But mayb= e > not. I'm at a bit of a disadvantage, because like 99.999% of the > population I'm still not entirely 100% clear on what can and can't > be done with these new WPA2 exploits. Please understand that if you can get an AP to hand you a zero'd key (with an intentionally "weak" client) THEN THAT PERSON JUST BECAME ABLE TO ATTACH TO YOUR NETWORK AS AN AUTHORIZED USER. Your network is thus exactly as "secure" as one that has an open RJ45 jack sitting at the end of your driveway and connected to your switch.=C2= =A0 If someone who plugged into that could screw you blind well, that's exactly the situation you're now in. Incidentally, has anyone yet figured out if this vector works on a network configured for machine certificates instead of a PSK?=C2=A0 I'm n= ot certain from what I've looked at yet, and that is bothering me a LOT for what should be obvious reasons. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070403050509010908050303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDE3MDIyNDM5 WjBPBgkqhkiG9w0BCQQxQgRAPEkuzQPsjPDX0Plv4lm5O3dM01rQWzRoE8yratB7bO9lJqCn AXmezIDOhHaztu3ikjN+ogYqLd4tb2fmcuTUsjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgC5LuJ4dJhSNmtuL1myEgIPMSEl8U8tCCX8QdQ8oDMwwzTVihn9ly44rVcER19WbJqJ swd+7/p/2z1/Izd/xIiF+wBC0eLRKdpTW/4rOXfwPKKaRuxb0SiBhbA6TIsL06EpLldJkSt/ Yy7EgsIkVcy/MYKbyaK4iRYym/lEMc5lYQkhgANZaQIaDH/vFZxrfApokS7FZ0zVaJ9puopT QFV8cDGcGGe3Nttt4bGAq2B0hx1SngNUnSNAgRC3rzkD1EqxnBpq6CcXEETSQUESR/iO/ehK e83BqbbGwACQkSwSytwFZmW2UrS7NV797DAM+oTE3FXG+ubgQ6zevrAFmiq7VIuFGhG9UDRf irGwytc6ZpbU4eaOS4UzbldLYHmgTJHN0Q4Ar2332xhqBm7YgX5MZv+mIWqsflsd95Wotykd P+PjBBFdoaXwc/yqM1DbbS9gK3acg9l3Ekv13H7aqcCJ3A4BR4CDvJmOdt3wPTp2F+CUuW97 V2jwxA1Sr9Uy78KUhD9M9cRz8ySSSIcBHKUUoT+fS27g3ECiHH6EFGu2XWCg9jilodoIzb2a 5bUjju6PCBYe49JRv/0apWOddJYXIEWEmuny8xriTEx+xJHFXusw7WSv+fqN+uoV6zqn5FfV B6J9NUwbyTLZT96qRzrrV3w6J9pLikqtG2XQdMEwHAAAAAAAAA== --------------ms070403050509010908050303-- From owner-freebsd-security@freebsd.org Tue Oct 17 03:17:33 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 54959E2911F for ; Tue, 17 Oct 2017 03:17:33 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 313577F1CE for ; Tue, 17 Oct 2017 03:17:32 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id D028C3AEFC for ; Mon, 16 Oct 2017 20:17:31 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response In-Reply-To: Date: Mon, 16 Oct 2017 20:17:31 -0700 Message-ID: <27467.1508210251@segfault.tristatelogic.com> 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: Tue, 17 Oct 2017 03:17:33 -0000 In message , Karl Denninger wrote: >Please understand that if you can get an AP to hand you a zero'd key >(with an intentionally "weak" client) THEN THAT PERSON JUST BECAME ABLE >TO ATTACH TO YOUR NETWORK AS AN AUTHORIZED USER. > >Your network is thus exactly as "secure" as one that has an open RJ45 >jack sitting at the end of your driveway and connected to your switch. >If someone who plugged into that could screw you blind well, that's >exactly the situation you're now in. Oh, geeezzzzzz. Marvelous... NOT! So, to recap, the options (for average JoeSchmos like me) seem to be: (1) Turn off WiFi entirely (and perhaps start stringing cables). (2) Treat -everything- that is connected to any typical SOHO WiFi router (which has WiFi enabled), regardless of whether the thing in question is hardwired or not, as being either/both (a) hostle and/or (b) directly attackable (as if attackers have a direct RJ45/twistedpair to it). (3) Leave everything as it is, for now, and just start praying that vendors and/or third parties will issue fixed firmware releases before the inevitable tech-savvy miscreants find their way to your specific neighborhood. Is that about the size of it? I'm not liking option 3 at all, but I'm not sure there is much else that I can do in the short run. (The only thing that, at the moment, is keeping me from being totally depressed about this whole gigantic mess is the sure and certain knowledge that several zillion people responsible for much more sensive networks than mine undoubtedly have much greater reasons for tearing their hair out this evening, and also in the days and weeks ahead.) A Question (which I already tried to ask): What about the clients? The impression I got is that WiFi -clients- will all need new firmware also. Yes? No? Is there any point to me calling and harassing Amazon to send me a firmware update for my Fire TV box? (I mean I do understand that even if one were available, that would hardly solve all of the problems on my network. But I'd just like to know what I should be agitating for in the weeks ahead. If the Wifi clients are entirely not a part of either the problem or the solution, then I won't worry about them.) From owner-freebsd-security@freebsd.org Tue Oct 17 08:27:15 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 3E3F6E3287D for ; Tue, 17 Oct 2017 08:27:15 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (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 0C7BE63C3C for ; Tue, 17 Oct 2017 08:27:14 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) X-Originating-IP: 93.26.153.77 Received: from [10.137.2.15] (77.153.26.93.rev.sfr.net [93.26.153.77]) (Authenticated sender: lists@whitewinterwolf.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id CC73841C089; Tue, 17 Oct 2017 10:27:05 +0200 (CEST) Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response To: "Ronald F. Guilmette" , freebsd-security@freebsd.org References: <25911.1508192029@segfault.tristatelogic.com> From: "WhiteWinterWolf (Simon)" Message-ID: <49252eda-3d48-f7bc-95e7-db716db4ed91@whitewinterwolf.com> Date: Tue, 17 Oct 2017 10:27:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <25911.1508192029@segfault.tristatelogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Tue, 17 Oct 2017 08:27:15 -0000 Hi Ronald, I have yet to investigate this WPA2 thing on my side, too much contradictory informations depending on the sources yet. Let me however add my two cents regarding your issue: A network can be divided in several logical layers: the data link layer (here WiFi), the networking layer (here TCP/IP), and the application with the data it manipulates, both in transit and at rest. Ideally, you would use a specific protection for each of these layers, so that an vulnerability affecting one layer would be compensated by other layers. But this "ideal solution" is not always feasible. What you did is secure only the lowest layers and put no security on the higher ones, the security of the complete stack relying on the lowest layer security. This is usually weak and prone to be vulnerable (if it wasn't due to this WPA2 weakness, it would be something else). There are however techniques allowing to secure higher layers without having to trust the lower ones. That's how, for instance, HTTPS work for online payment: neither you nor the bank or merchant trusts the Internet network, but all sensitive operations are done within a secure tunnel created between you and the remote party and isolating you form any threat affecting networks in between. This WPA2 crisis strongly reminds me WEP (even-though I don't know yet if it is really as scary: again different source gives completely different information). But nevertheless at that time it was simply assumed that the Wi-Fi was just to be considered as an untrusted network, the same way as you (should) consider Internet. A sane approach which was usually recommended was as follow: 1) Sensitive accesses must be properly secured. As you cannot trust lower layers, use something like a VPN, which is able to authenticate both the source and destination hosts and create a secure tunnel between them. At the time of the WEP issue, there was a movement to completely drop any kind of WiFi "security" and use plain, open WiFi instead but rely on VPN to authenticate the hosts and provide appropriate access and security. This was maybe an extreme position, but still this shows the idea and remains secure indeed, as long as all your hosts support VPN of course. 2) Non-sensitive accesses *may* use lower security if needed. In particular, I don't think that your Amazon TV supports any kind of VPN tunneling, but also I don't know if it requires write access to your network share or if it uses it only to read non-sensitive media files. A common scenario is to allow read-only access limited to non-sensitive documents over the untrusted WiFi network. Yes, an attacker can take over your network and copy your movies and musics, but is this really problem for you? IT security is always a question of trade-offs depending on your particular situation, but for the "few zillions" you mentioned this is usually not a problem (and actually the attacker will most likely not even care of such files). All sensitive operations should be done using secure channels. The most versatile secure channel is setting-up a custom VPN within your LAN, but there are other alternatives. For instance, to update the content of your shared directories, you can use SFTP instead (the SSH file transfer protocol) instead of a writable share: this is very easy to setup (FileZilla is an easy to use and well-known SFTP client) and the whole communication will be secured by SSH. At last remains Internet access. There are two threats there: 1) An attacker may intercept your connection. He will not be in measure to bypass HTTPS security though, so assertion such a "hacker can now steal your passwords and credit card numbers" as heard this morning in the news is bullshit as long as you ensure that your connection is indeed secure through HTTPS thanks to the little padlock. There are paid VPN services available on the Internet, some of them even proposing smartphone apps. They are commonly and effectively used on public WiFi network which are by definition untrusted, and would be an easy way to secure your Internet access through an untrusted WiFi without having to learn to setup a VPN server yourself. 2) An attacker may use your Internet access for his own purposes. At the peak of the WEP crisis, maps of location of weak WEP Internet access points were shared (for a fee, I guess, everything is a matter of business) on shady forums (typically pedo-pornographic forums) so their users can take advantage of such unsecured networks to access illegal content anonymously. Your WiFi access point firewall may offer the possibility to restrict outgoing connections to only the VPN server. This would effectively restrict Internet access to hosts and devices able to authenticate against the VPN server. Not the ideal solution in case of a public VPN server (where everyone can subscribe), but enough to deter such low-tech attackers who just seek for ready-made available Internet accesses. So, to summarize: - Unsecure shares must be read-only and offer access to only non-sensitive files. - Write accesses and access to sensitive files must be done through secure channels authenticating both the server and the client. SFTP is a common solution, with FileZilla a widely used client. - If an Internet access is needed over the WiFi, public VPN services offer ready-to-use solutions. - Restricting outgoing access to the VPN server will prevent casual attackers from taking advantage of your Internet connection. None of this requires high amount of technical knowledge and allows to provide a good level of security independently of your WiFi security level. I hope these few elements help you to see things a bit clearer and, maybe, give you some useful ideas. Regards, Simon. -- WhiteWinterWolf https://www.whitewinterwolf.com From owner-freebsd-security@freebsd.org Tue Oct 17 10:17:58 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 12FF6E35557 for ; Tue, 17 Oct 2017 10:17:58 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (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 D0CC266A6A for ; Tue, 17 Oct 2017 10:17:57 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) X-Originating-IP: 93.26.153.77 Received: from [10.137.2.15] (77.153.26.93.rev.sfr.net [93.26.153.77]) (Authenticated sender: lists@whitewinterwolf.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id C6F6841C08B; Tue, 17 Oct 2017 12:17:55 +0200 (CEST) Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response To: Karl Denninger , freebsd-security@freebsd.org References: <27180.1508206466@segfault.tristatelogic.com> From: "WhiteWinterWolf (Simon)" Message-ID: Date: Tue, 17 Oct 2017 12:17:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Tue, 17 Oct 2017 10:17:58 -0000 Hi Karl, Le 17/10/2017 à 04:24, Karl Denninger a écrit : > Please understand that if you can get an AP to hand you a zero'd key > (with an intentionally "weak" client) THEN THAT PERSON JUST BECAME > ABLE TO ATTACH TO YOUR NETWORK AS AN AUTHORIZED USER. As per my understanding, this attack only allows to join the network in the case of Wireless Gigabit GCMP (WiGig) which is currently uncommon. Common implementations such as WPA2 CCMP and legacy WPA TKIP only allow the attacker to intercept and manipulate transmitted data. No way has been found yet for the attacker to forge handshake messages, join a network or otherwise determine network's password. Moreover, traffic interception either requires the traffic to be in clear form or communication security to be poorly implemented. I personally hope this will again raise the interest toward a fully encrypted Internet and clear communication becoming the exception instead of the norm. Clear-text transmission of user's data is a plague which should be removed. > Incidentally, has anyone yet figured out if this vector works on a > network configured for machine certificates instead of a PSK? I'm not > certain from what I've looked at yet, and that is bothering me a LOT > for what should be obvious reasons. Yes, as the author states in the attacks details[1] this attack also affect enterprise WiFi networks, and both client and server must be patched for the fix to work so any unpatched device (BYOD...) will remain a vulnerable point in the corporate infrastructure. [1]: https://www.krackattacks.com/#details -- WhiteWinterWolf https://www.whitewinterwolf.com From owner-freebsd-security@freebsd.org Tue Oct 17 18:22:52 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 ADC90E42CBB for ; Tue, 17 Oct 2017 18:22:52 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91E2E7CDE5; Tue, 17 Oct 2017 18:22:52 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 945) id E7A1F123E5; Tue, 17 Oct 2017 18:22:51 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-17:07.wpa Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20171017182251.E7A1F123E5@freefall.freebsd.org> Date: Tue, 17 Oct 2017 18:22:51 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 18:22:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-17:07.wpa Security Advisory The FreeBSD Project Topic: WPA2 protocol vulnerability Category: contrib Module: wpa Announced: 2017-10-16 Credits: Mathy Vanhoef Affects: All supported versions of FreeBSD. Corrected: 2017-10-17 17:30:18 UTC (stable/11, 11.1-STABLE) 2017-10-17 17:57:18 UTC (releng/11.1, 11.1-RELEASE-p2) 2017-10-17 17:56:03 UTC (releng/11.0, 11.0-RELEASE-p13) CVE Name: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background Wi-Fi Protected Access II (WPA2) is a security protocol developed by the Wi-Fi Alliance to secure wireless computer networks. hostapd and wpa_supplicant are implementations of user space daemon for access points and wireless client that implements the WPA2 protocol. II. Problem Description A vulnerability was found in how a number of implementations can be triggered to reconfigure WPA/WPA2/RSN keys (TK, GTK, or IGTK) by replaying a specific frame that is used to manage the keys. III. Impact Such reinstallation of the encryption key can result in two different types of vulnerabilities: disabling replay protection and significantly reducing the security of encryption to the point of allowing frames to be decrypted or some parts of the keys to be determined by an attacker depending on which cipher is used. IV. Workaround An updated version of wpa_supplicant is available in the FreeBSD Ports Collection. Install version 2.6_2 or later of the security/wpa_supplicant port/pkg. Once installed, update /etc/rc.conf to use the new binary: wpa_supplicant_program="/usr/local/sbin/wpa_supplicant" and restart networking. An updated version of hostapd is available in the FreeBSD Ports Collection. Install version 2.6_1 or later of the net/hostapd port/pkg. Once installed, update /etc/rc.conf to use the new binary: hostapd_program="/usr/local/sbin/hostapd" and restart hostapd. V. Solution Patches are currently available for stable/11, releng/11.0, and releng/11.1. Patches for stable/10, releng/10.3, and releng/10.4 are still being evaluated. Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Restart the Wi-Fi network interfaces/hostapd or reboot the system. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install Restart the Wi-Fi network interfaces/hostapd or reboot the system. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 11.0-RELEASE, 11.1-RELEASE, and 11-STABLE] # fetch https://security.FreeBSD.org/patches/SA-17:07/wpa-11.patch # fetch https://security.FreeBSD.org/patches/SA-17:07/wpa-11.patch.asc # gpg --verify wpa-11.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart the applicable daemons, or reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/11/ r324697 releng/11.0/ r324698 releng/11.1/ r324699 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEHPf/b631yp++G4yy7Wfs1l3PaucFAlnmRUZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDFD RjdGRjZGQURGNUNBOUZCRTFCOENCMkVENjdFQ0Q2NURDRjZBRTcACgkQ7Wfs1l3P aueKcxAAwObogcEZAgGioU4uZvk9kKIpmG/NwvUjcZ0viFhePowKnh6/UoFDd+13 NsjriznPNKbXPch2Gp3Zwgd/hff10vlvr69QOFXnI3/Y8b+thxkl1kCAxC0xkfEl eQBzjllMrjtrSgfKtoWInxnZLIrghuJAg4Jvvz+uWd3VTggM0pQgLUuhR/a8lWHd 3HBj5//sOhmVW2OFYC5dskYAn6TqyHtlMP9AT32h6QEyEzJeNWMlToELxy6OK59j MYaS0vclz7QT+4SATvcl8RCmxmYfyWxEtFhDmPNz4mfQ915AxTjGFv7KbjTZtunl k3niR3O8F450xduw5Yj9Mz3YdZ4ZYmvHbDgQLsMNwAmtQvXSteXUUBVNVAg9PsjR 4kxlEFsStWh6CtJVKYUvKDThnHrWYLiVUh6o/FtRm5fx2ws/gcj7H9csr8mQ0pkO zm9jVOgMe7pqI7gygOfb61Rjz6PnLgVQcnP2LoC9pB21O5Q/Q2rv9d6XN3mQ6CQ2 +mUEZ5M7TWyd6gFrP2Eu6srec1nT1NjVjzyyupgusiQve3xV0wacG0jwgy7+VXE8 Ls2a/SObVDZkvFhOYMrLVui33l7f/vgT0KImyO2fkaWjbDcEyVcm1f+A7K+hqwp8 2O/Eh+NVSG0GIbt9pro0BxsZhMb/V4WmWV+4WnLKPwCQZ9fimKA= =aNWn -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Tue Oct 17 19:44:38 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 676A7E45BB9 for ; Tue, 17 Oct 2017 19:44:38 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [213.239.241.64]) (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 11D39803D4 for ; Tue, 17 Oct 2017 19:44:37 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from [IPv6:2001:470:25:233:24ef:84:9b8f:b3c] (unknown [IPv6:2001:470:25:233:24ef:84:9b8f:b3c]) by host64.shmhost.net (Postfix) with ESMTPSA id B0907160676 for ; Tue, 17 Oct 2017 21:44:28 +0200 (CEST) From: Franco Fichtner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-17:07.wpa Date: Tue, 17 Oct 2017 21:44:27 +0200 References: <20171017182251.E38B8123E3@freefall.freebsd.org> To: freebsd-security@freebsd.org In-Reply-To: <20171017182251.E38B8123E3@freefall.freebsd.org> Message-Id: X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at host64.shmhost.net X-Virus-Status: Clean X-Spam-Flag: NO X-Spam-Score: -1.0 X-Spam-Status: No score=-1.0 tagged_above=10.0 required=10.0 tests=[ALL_TRUSTED] 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: Tue, 17 Oct 2017 19:44:38 -0000 Hi, The entry in UPDATING on releng/11.1 annotates "p13" but should say = "p2". Cheers, Franco > On 17. Oct 2017, at 8:22 PM, FreeBSD Security Advisories = wrote: >=20 > Signed PGP part > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > FreeBSD-SA-17:07.wpa Security = Advisory > The FreeBSD = Project >=20 > Topic: WPA2 protocol vulnerability >=20 > Category: contrib > Module: wpa > Announced: 2017-10-16 > Credits: Mathy Vanhoef > Affects: All supported versions of FreeBSD. > Corrected: 2017-10-17 17:30:18 UTC (stable/11, 11.1-STABLE) > 2017-10-17 17:57:18 UTC (releng/11.1, 11.1-RELEASE-p2) > 2017-10-17 17:56:03 UTC (releng/11.0, = 11.0-RELEASE-p13) > CVE Name: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, > CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, > CVE-2017-13086, CVE-2017-13087, CVE-2017-13088 >=20 > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . >=20 > I. Background >=20 > Wi-Fi Protected Access II (WPA2) is a security protocol developed by = the > Wi-Fi Alliance to secure wireless computer networks. >=20 > hostapd and wpa_supplicant are implementations of user space daemon = for > access points and wireless client that implements the WPA2 protocol. >=20 > II. Problem Description >=20 > A vulnerability was found in how a number of implementations can be > triggered to reconfigure WPA/WPA2/RSN keys (TK, GTK, or IGTK) by > replaying a specific frame that is used to manage the keys. >=20 > III. Impact >=20 > Such reinstallation of the encryption key can result in two different > types of vulnerabilities: disabling replay protection and = significantly > reducing the security of encryption to the point of allowing frames to > be decrypted or some parts of the keys to be determined by an attacker > depending on which cipher is used. >=20 > IV. Workaround >=20 > An updated version of wpa_supplicant is available in the FreeBSD Ports > Collection. Install version 2.6_2 or later of the > security/wpa_supplicant port/pkg. Once installed, update /etc/rc.conf > to use the new binary: >=20 > wpa_supplicant_program=3D"/usr/local/sbin/wpa_supplicant" >=20 > and restart networking. >=20 > An updated version of hostapd is available in the FreeBSD Ports > Collection. Install version 2.6_1 or later of the net/hostapd = port/pkg. > Once installed, update /etc/rc.conf to use the new binary: >=20 > hostapd_program=3D"/usr/local/sbin/hostapd" >=20 > and restart hostapd. >=20 > V. Solution >=20 > Patches are currently available for stable/11, releng/11.0, and > releng/11.1. Patches for stable/10, releng/10.3, and releng/10.4 are > still being evaluated. >=20 > Perform one of the following: >=20 > 1) Upgrade your vulnerable system to a supported FreeBSD stable or > release / security branch (releng) dated after the correction date. >=20 > Restart the Wi-Fi network interfaces/hostapd or reboot the system. >=20 > 2) To update your vulnerable system via a binary patch: >=20 > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: >=20 > # freebsd-update fetch > # freebsd-update install >=20 > Restart the Wi-Fi network interfaces/hostapd or reboot the system. >=20 > 3) To update your vulnerable system via a source code patch: >=20 > The following patches have been verified to apply to the applicable > FreeBSD release branches. >=20 > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. >=20 > [FreeBSD 11.0-RELEASE, 11.1-RELEASE, and 11-STABLE] > # fetch https://security.FreeBSD.org/patches/SA-17:07/wpa-11.patch > # fetch https://security.FreeBSD.org/patches/SA-17:07/wpa-11.patch.asc > # gpg --verify wpa-11.patch.asc >=20 > b) Apply the patch. Execute the following commands as root: >=20 > # cd /usr/src > # patch < /path/to/patch >=20 > c) Recompile the operating system using buildworld and installworld as > described in . >=20 > Restart the applicable daemons, or reboot the system. >=20 > VI. Correction details >=20 > The following list contains the correction revision numbers for each > affected branch. >=20 > Branch/path = Revision > = ------------------------------------------------------------------------- > stable/11/ = r324697 > releng/11.0/ = r324698 > releng/11.1/ = r324699 > = ------------------------------------------------------------------------- >=20 > To see which files were modified by a particular revision, run the > following command, replacing NNNNNN with the revision number, on a > machine with Subversion installed: >=20 > # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base >=20 > Or visit the following URL, replacing NNNNNN with the revision number: >=20 > >=20 > VII. References >=20 > = > >=20 > The latest revision of this advisory is available at > >=20 > _______________________________________________ > freebsd-announce@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-announce > To unsubscribe, send any mail to = "freebsd-announce-unsubscribe@freebsd.org" From owner-freebsd-security@freebsd.org Wed Oct 18 04:00:19 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 C43C3E4EB21 for ; Wed, 18 Oct 2017 04:00:19 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF8569489 for ; Wed, 18 Oct 2017 04:00:18 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id EFF3B3AEF8 for ; Tue, 17 Oct 2017 21:00:11 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response In-Reply-To: <49252eda-3d48-f7bc-95e7-db716db4ed91@whitewinterwolf.com> Date: Tue, 17 Oct 2017 21:00:11 -0700 Message-ID: <32999.1508299211@segfault.tristatelogic.com> 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: Wed, 18 Oct 2017 04:00:19 -0000 In message <49252eda-3d48-f7bc-95e7-db716db4ed91@whitewinterwolf.com>, "WhiteWinterWolf (Simon)" wrote: >Ideally, you would use a specific protection for each of these layers, >so that an vulnerability affecting one layer would be compensated by >other layers. A good point. Right about now, I wish that I knew one hell of a lot more about both NFS and SMB than I do... and also SSH and TLS. I suspect that the file sharing protocols I am most concerned about (NFS & SMB) could perhaps be run in a manner such that both initial volume mounts and also data blocks (to & from) the share volumes would be additionally encrypted, so that I could be running everything securely, even if some attacker managed to do maximally evil things to my WiFi/WPA2 network. Do NFS and/or SMB have their own built-in encryption? I have to ask, because I honestly don't know. If not, is it easily possible to add or attach some additional encryption layer to those? And if I did so, would it even help any? (I'm guessing that it might, just on the basis of what little I know about SSH. I don't even really know how SSH works. The only think I do know is that it is possible to use it to both start up and continue a secure connection, even in the presence of utterly compromised data links. And I gather than this is also -the- fundamental and inherent feature of TLS also.) Please note that I am asking only about what is -easily- possible. I wish that I had time to learn in depth about all things crypto (starting from my very low starting point) but I don't. And I'm just running a little home network here, not a network for, say, a huge corporation or for a sprawling factory floor. So I just doesn't make sense for me to spend, say, 200 man hours to get something working. I just don't have that kind of time to devote to this. Basically if there is an -eay- crypto-protected way of mounting volumes and then accessing them, either for NFS or for SMB (or both) then I do think I'd like to try that. >What you did is secure only the lowest layers and put no security on the >higher ones, the security of the complete stack relying on the lowest >layer security. Yea, I think that I sort of got that. >All sensitive operations should be done using secure channels. >The most versatile secure channel is setting-up a custom VPN within your >LAN... Frankly, I must sheepishly admit that have no idea how to even begin to do that. Pointers to tutorials would be appreciated. Note also that whatever I do in this regard, I have to be able to entice or coerce at least one of (a) OpenELEC/LibreELEC and/or (b) Windoze7 to follow suit. >At last remains Internet access. There are two threats there: > >1) An attacker may intercept your connection. He will not be in measure >to bypass HTTPS security though, so assertion such a "hacker can now >steal your passwords and credit card numbers" as heard this morning in >the news is bullshit as long as you ensure that your connection is >indeed secure through HTTPS thanks to the little padlock. Well, as I mentioned earlier, my Amazon Fire TV box doesn't need to access anything from my local file server, but it *does* somehow (and mostly automagically) access protected content off the Internet, via my local WiFi network. At the moment, I don't even know if whatever credentials of mine that are stored in, and transmitted from that box are at risk, and I have even less of an idea of how to secure them if they are indeed at risk. >There are paid VPN services available on the Internet, some of them even >proposing smartphone apps. They are commonly and effectively used on >public WiFi network which are by definition untrusted, and would be an >easy way to secure your Internet access through an untrusted WiFi >without having to learn to setup a VPN server yourself. Right, but how do I entice the Fire TV box to use such a thing? That's the enigma, I think... at least for me. >2) An attacker may use your Internet access for his own purposes. Yea, I've gathered at least that much. It is a worrying possibility, but as I have pretty crappy (low) bandwidth, I think that if bad guys show up in my neighborhood, they will easily find much better pickings from some of my neighbors. So for the moment, I'm not going to worry about this, but of course, I'm going keep my ear to the ground, and will patch my router and my WiFi clients the minute patches or these things are available. >Your WiFi access point firewall may offer the possibility to restrict >outgoing connections to only the VPN server. This would effectively >restrict Internet access to hosts and devices able to authenticate >against the VPN server. It doesn't. :-( >I hope these few elements help you to see things a bit clearer and, >maybe, give you some useful ideas. Yes, thanks. I feel sure that I am probably speaking for a few hundred million people, all over the world, when I say that this whole WPA2 debacle is really rather entirely annoying. But with helpful folks like you around, even the dunderheads like me will probably manage to make it through this mess without too much pain. Thanks for your thoughts. Regards, rfg From owner-freebsd-security@freebsd.org Wed Oct 18 17:27:52 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 44320E3FAC3 for ; Wed, 18 Oct 2017 17:27:52 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (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 139B43F4B for ; Wed, 18 Oct 2017 17:27:51 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) X-Originating-IP: 93.26.153.77 Received: from [10.137.2.15] (77.153.26.93.rev.sfr.net [93.26.153.77]) (Authenticated sender: lists@whitewinterwolf.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 17D491720B4; Wed, 18 Oct 2017 19:27:42 +0200 (CEST) Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response To: "Ronald F. Guilmette" , freebsd-security@freebsd.org References: <32999.1508299211@segfault.tristatelogic.com> From: "WhiteWinterWolf (Simon)" Message-ID: <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> Date: Wed, 18 Oct 2017 19:27:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <32999.1508299211@segfault.tristatelogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Wed, 18 Oct 2017 17:27:52 -0000 Hi Ronald, Le 18/10/2017 à 06:00, Ronald F. Guilmette a écrit : > > In message <49252eda-3d48-f7bc-95e7-db716db4ed91@whitewinterwolf.com>, > "WhiteWinterWolf (Simon)" wrote: > >> Ideally, you would use a specific protection for each of these layers, >> so that an vulnerability affecting one layer would be compensated by >> other layers. > > A good point. > > Right about now, I wish that I knew one hell of a lot more about both > NFS and SMB than I do... and also SSH and TLS. I suspect that the > file sharing protocols I am most concerned about (NFS & SMB) could > perhaps be run in a manner such that both initial volume mounts and > also data blocks (to & from) the share volumes would be additionally > encrypted, so that I could be running everything securely, even if > some attacker managed to do maximally evil things to my WiFi/WPA2 > network. > > Do NFS and/or SMB have their own built-in encryption? No, not really. NFS has no built-in encryption, it may be possible to tunnel it but this is out-of-scope here (using a VPN and tunnel everything would be easier than nitpicking and tunnel only the NFS data flow). SMB has no widely compatible encryption: - Microsoft has built its own, proprietary encryption available and compatible only with the latest Windows versions. - Open source implementations rely on TLS, natively supported by some client but requiring (AFAIK) `stunnel` server-side. > Please note that I am asking only about what is -easily- possible. Securing in-transit NFS and SMB communication is not part of this. > I don't even really know how SSH works. I don't know what kind of device / server you are using to store and share your files. If your files repository proposes a web interface, it may be as simple as going in the SSH/SFTP tab, check the "enable" box, and access your files through an SFTP-capabe client such as FileZilla (AFAIK, FreeNAS, since we are on a FreeBSD mailing list, supports SFTP shares natively). For a basic usage you don't need to dig into the details of how the SSH protocol works and the impressive number of features it offers. Simply know that one of its features is SFTP, standing for Secure File Transfer Protocol, so when you need a protocol to securely transfer files then SFTP can do it. > The only think I do know is that it is possible to use it to both start > up and continue a secure connection, even in the presence of utterly > compromised data links. And I gather than this is also -the- fundamental > and inherent feature of TLS also.) You're right. > Please note that I am asking only about what is -easily- possible. I > wish that I had time to learn in depth about all things crypto (starting > from my very low starting point) but I don't. And I'm just running a > little home network here, not a network for, say, a huge corporation > or for a sprawling factory floor. So I just doesn't make sense for me > to spend, say, 200 man hours to get something working. I just don't > have that kind of time to devote to this. I understand, that's why I mention SFTP which is usually a widely supported, painless and secure way to transfer files over a potentially untrusted network. > Basically if there is an -easy- crypto-protected way of mounting volumes > and then accessing them, either for NFS or for SMB (or both) then I do > think I'd like to try that. This is becoming more-and-more a concern. NFS, but that's my opinion, is a rather historical protocol so I don't think there will be any major evolution there. As stated above, the SMB protocol is evolving to better protect in-transit data, but there are business interests here at play which prevents, for now, the users from having any simple and widely-compatible solution. As a reminder SMB is an undocumented proprietary protocol from Microsoft. Open-source implementations have been done by individuals reverse-engineering Microsoft's own work. Having Microsoft and the open-source community stretching in different directions pursuing different goals is not the best situation for a quick and sane evolution of the protocol. >> All sensitive operations should be done using secure channels. >> The most versatile secure channel is setting-up a custom VPN within your >> LAN... > > Frankly, I must sheepishly admit that have no idea how to even begin to > do that. Pointers to tutorials would be appreciated. > Hence the following of my sentence: "but there are other alternative". "Versatile" and "easy-to-use" are often very different things. > Note also that whatever I do in this regard, I have to be able to entice > or coerce at least one of (a) OpenELEC/LibreELEC and/or (b) Windoze7 > to follow suit. For OpenElec, this may become an issue if you are using it to access sensitive files. But usually this is not the case. For "Windoze7", according to this post: https://security.stackexchange.com/q/171542/32746#171546 It seems that updating the client might be enough to thwart most of the attack. Windows 7 is still supported for security updates, so I don't doubt that Microsoft will release a fix for this system if this is not already done. Other than that, there are various solutions to protect browsing data: - You can use a paid VPN service. Again, you don't need to learn how to setup a VPN: all the work is done by the VPN provider services and they provide straightforward assistants to automatically configure your system. - You can use EFF's HTTPS Everywhere add-on and configure it to access only HTTPS websites, but this will most likely block a lot of websites. - Some browsers include proxy capability natively to protect your data from untrusted network, such as the Opera with its "VPN" feature and the TOR browser. The advantage is that such solution would work everywhere, so you can take your Windows 7 laptop at a cyber-cafe or access an airport WiFi and still benefit from the level of safety in your browsing than at your home. > Well, as I mentioned earlier, my Amazon Fire TV box doesn't need to > access anything from my local file server, but it *does* somehow > (and mostly automagically) access protected content off the Internet, > via my local WiFi network. At the moment, I don't even know if > whatever credentials of mine that are stored in, and transmitted from > that box are at risk, and I have even less of an idea of how to > secure them if they are indeed at risk. Amazon seems to be currently working on this: https://www.aivanet.com/2017/10/amazon-says-a-patch-for-wpa2-exploit-krack-is-in-the-works/ As always, with proprietary devices and software you are not in control on what the device is doing, don't even have any reliable understanding of it and rely on the upstream vendor for any change. >> 2) An attacker may use your Internet access for his own purposes. > > Yea, I've gathered at least that much. It is a worrying possibility, Not so worrying actually. Now that I've better checked this new attack, it doesn't sound as devastating as the previously mentioned WEP issues, at least not in its current stage (and WPA2 being better engineered than WEP, chances are that the story will not repeat). An attacker is able to join the WiFi network only if you use Wireless Gigabit (WiGig) which is quite uncommon. Common WiFi access (WPA2 CCMP, WPA TKIP) only allow an attacker to intercept and manipulate users data, not to join the network or obtain the network's password. > but as I have pretty crappy (low) bandwidth, I think that if bad guys > show up in my neighborhood, they will easily find much better pickings > from some of my neighbors. So for the moment, I'm not going to worry > about this, but of course, I'm going keep my ear to the ground, and will > patch my router and my WiFi clients the minute patches or these things > are available. Patches for computer-based devices should come very soon (if not already available). Depending on the providers and involved parties, it may take more time for mobile devices and router firmwares (the worst case being carrier-provided previous-generation Android smartphones: I wouldn't be surprised that a large portion of them will never be fixed). > I feel sure that I am probably speaking for a few hundred million people, > all over the world, when I say that this whole WPA2 debacle is really > rather entirely annoying. But with helpful folks like you around, even > the dunderheads like me will probably manage to make it through this mess > without too much pain. Thank you for your kind words. At least, the mediatisation of this flaw puts pressure on software and devices providers to fix this flaw and not ignore it. Maybe, the most useful thing that this "hundred million people" can do is keep an eye on these providers and push to get it fixed. Manufacturers often neglect security for end-users devices (it costs money while not being a selling-point). Such "debacle" may be have its advantages from time-to-time to make people think on how they use their devices. As a security engineer, I obviously campaign for safer devices and tools which provide security without even the user noticing it. But there are other interests in the field, so it may not be completely bad that people are reminded that technology may not be blindly relied upon. Regards, Simon. -- WhiteWinterWolf https://www.whitewinterwolf.com From owner-freebsd-security@freebsd.org Wed Oct 18 20:52:43 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 2B4F2E43BD0 for ; Wed, 18 Oct 2017 20:52:43 +0000 (UTC) (envelope-from walterp@gmail.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8CE169E48 for ; Wed, 18 Oct 2017 20:52:42 +0000 (UTC) (envelope-from walterp@gmail.com) Received: by mail-qk0-x235.google.com with SMTP id n5so7921720qke.11 for ; Wed, 18 Oct 2017 13:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=odsY3laA1eF6Imcl3msfjv4JqSW51O/BWw2sZd4D6X8=; b=uLknnk+VJ4oeiy/6PR1KbVR0XiQjxmTTSfTGIxWyQzB+06IoKn5+vhfeN94zv2ALLr +A23Bkam4ca1tCCAWFcvDq7/oKUmYizNv3vLl1TF631icgwVsCmYVKyaCc4P1joHrUqn tuJEBIkssnrJfMEsjRxjkDJfxG1MnGiPQYtKH1YNSTNUqQMuDCtWVE5SYpXNEaBSjXBr +xTHZR4t+HtoNuezPYHzdN4SBo8mvTVPL3upj2XxSUeP88/de+pJBXz2mJAOCmgUWgK+ ifWqVTBhzs3cjI1vXSG54VH+WrFALmEV+Gpw2kP+dMU87PBKHuiaKQnz54p6Ni3yx41r IxMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=odsY3laA1eF6Imcl3msfjv4JqSW51O/BWw2sZd4D6X8=; b=rUrbJ42sGOSBHH6OgCz1RDeaW1fml6wHYR3KY6y+beZI8AwvrrWZoCRjjgLqoqxa9y JbQ4V0m006M/wBPliMsZ8QvSIB09cLOa+V5r1YOkIQccNKrzctCa3AwMGmZfDYt/54K2 SdnvfZRXI3z5QCuR5kRMi1LnG9c3O4b7eL4qyX4/3pk79wYU4qL9rITiW2d11ssJWWKQ dwj4c4uDZ9vrqUMaH9IoYsBAog/SW4Ed6b4FbyY4QtHVo9WoJJsZRdE2DZjEMBf1HNIp O4fy46hUCKXFmc8U9d4ZgLLSGSaLoL8J4DfpU+Y+eXFKiuogzObk2p1JHzfnV5OKEOJl xqVA== X-Gm-Message-State: AMCzsaWwnladU4Duscwzysu9FxwChX+FTtIyhZ1mZoCR0wFQIc7z01Zp KwTvnGUkwpSWtvaynTXgbdrYf7Bx/6PmP8NdTXk= X-Google-Smtp-Source: ABhQp+R7TtKhwsGn/B55Kll41NXXkCXkT6bNZa0PokpNYSPebmbRUL9Bahud0IGbhOzfkqW0RrnoxtK/Lc9rNHWTJOE= X-Received: by 10.55.109.131 with SMTP id i125mr4103496qkc.219.1508359961746; Wed, 18 Oct 2017 13:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.181.165 with HTTP; Wed, 18 Oct 2017 13:52:41 -0700 (PDT) In-Reply-To: References: From: Walter Parker Date: Wed, 18 Oct 2017 13:52:41 -0700 Message-ID: Subject: Re: freebsd-security Digest, Vol 634, Issue 3 To: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Wed, 18 Oct 2017 20:52:43 -0000 > > > > Message: 3 > Date: Tue, 17 Oct 2017 21:00:11 -0700 > From: "Ronald F. Guilmette" > To: freebsd-security@freebsd.org > Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response > Message-ID: <32999.1508299211@segfault.tristatelogic.com> > > > In message <49252eda-3d48-f7bc-95e7-db716db4ed91@whitewinterwolf.com>, > "WhiteWinterWolf (Simon)" wrote: > > >Ideally, you would use a specific protection for each of these layers, > >so that an vulnerability affecting one layer would be compensated by > >other layers. > > A good point. > > Right about now, I wish that I knew one hell of a lot more about both > NFS and SMB than I do... and also SSH and TLS. I suspect that the > file sharing protocols I am most concerned about (NFS & SMB) could > perhaps be run in a manner such that both initial volume mounts and > also data blocks (to & from) the share volumes would be additionally > encrypted, so that I could be running everything securely, even if > some attacker managed to do maximally evil things to my WiFi/WPA2 > network. > > Do NFS and/or SMB have their own built-in encryption? I have to ask, > because I honestly don't know. If not, is it easily possible to add > or attach some additional encryption layer to those? And if I did so, > would it even help any? (I'm guessing that it might, just on the basis > of what little I know about SSH. I don't even really know how SSH works. > The only think I do know is that it is possible to use it to both start > up and continue a secure connection, even in the presence of utterly > compromised data links. And I gather than this is also -the- fundamental > and inherent feature of TLS also.) > > Please note that I am asking only about what is -easily- possible. I > wish that I had time to learn in depth about all things crypto (starting > from my very low starting point) but I don't. And I'm just running a > little home network here, not a network for, say, a huge corporation > or for a sprawling factory floor. So I just doesn't make sense for me > to spend, say, 200 man hours to get something working. I just don't > have that kind of time to devote to this. > > Basically if there is an -eay- crypto-protected way of mounting volumes > and then accessing them, either for NFS or for SMB (or both) then I do > think I'd like to try that. > > >What you did is secure only the lowest layers and put no security on the > >higher ones, the security of the complete stack relying on the lowest > >layer security. > > Yea, I think that I sort of got that. > > >All sensitive operations should be done using secure channels. > >The most versatile secure channel is setting-up a custom VPN within your > >LAN... > > Frankly, I must sheepishly admit that have no idea how to even begin to > do that. Pointers to tutorials would be appreciated. > > Note also that whatever I do in this regard, I have to be able to entice > or coerce at least one of (a) OpenELEC/LibreELEC and/or (b) Windoze7 > to follow suit. > > >At last remains Internet access. There are two threats there: > > > >1) An attacker may intercept your connection. He will not be in measure > >to bypass HTTPS security though, so assertion such a "hacker can now > >steal your passwords and credit card numbers" as heard this morning in > >the news is bullshit as long as you ensure that your connection is > >indeed secure through HTTPS thanks to the little padlock. > > Well, as I mentioned earlier, my Amazon Fire TV box doesn't need to > access anything from my local file server, but it *does* somehow > (and mostly automagically) access protected content off the Internet, > via my local WiFi network. At the moment, I don't even know if > whatever credentials of mine that are stored in, and transmitted from > that box are at risk, and I have even less of an idea of how to > secure them if they are indeed at risk. > > >There are paid VPN services available on the Internet, some of them even > >proposing smartphone apps. They are commonly and effectively used on > >public WiFi network which are by definition untrusted, and would be an > >easy way to secure your Internet access through an untrusted WiFi > >without having to learn to setup a VPN server yourself. > > Right, but how do I entice the Fire TV box to use such a thing? That's > the enigma, I think... at least for me. > > >2) An attacker may use your Internet access for his own purposes. > > Yea, I've gathered at least that much. It is a worrying possibility, > but as I have pretty crappy (low) bandwidth, I think that if bad guys > show up in my neighborhood, they will easily find much better pickings > from some of my neighbors. So for the moment, I'm not going to worry > about this, but of course, I'm going keep my ear to the ground, and will > patch my router and my WiFi clients the minute patches or these things > are available. > > >Your WiFi access point firewall may offer the possibility to restrict > >outgoing connections to only the VPN server. This would effectively > >restrict Internet access to hosts and devices able to authenticate > >against the VPN server. > > It doesn't. :-( > > >I hope these few elements help you to see things a bit clearer and, > >maybe, give you some useful ideas. > > Yes, thanks. > > I feel sure that I am probably speaking for a few hundred million people, > all over the world, when I say that this whole WPA2 debacle is really > rather entirely annoying. But with helpful folks like you around, even > the dunderheads like me will probably manage to make it through this mess > without too much pain. > > Thanks for your thoughts. > > > Regards, > rfg > > SMB has supported authentication signing for a long time (more than a decade). That can be used for basic security. SMB3 supports encryption. To work with SMB3 encryption you will need at least Windows 8. The Samba project supports SMB3 and many of the security features in it, but not share level encryption. Password authentication works with signing and encryption. Until Samba supports the new share encryption in SMB3, you will need to use something like stunnel (or an encrypted VPN) to enable the privacy features that come with encryption. What that means is that the newest versions of Samba can talk to newer Windows boxes with the authentication pieces (the username/password exchange) done with encryption to make exploitation much harder. Encryption on NFS appears to be by using stunnel or SSH to encrypt the data (or using a VPN). Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis From owner-freebsd-security@freebsd.org Wed Oct 18 22:49:06 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 4EC62E45EEF for ; Wed, 18 Oct 2017 22:49:06 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 DAB3C6D2E0 for ; Wed, 18 Oct 2017 22:49:05 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-f87ff70000007b75-3c-59e7d9276f98 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 02.AB.31605.829D7E95; Wed, 18 Oct 2017 18:43:53 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v9IMhm92030346; Wed, 18 Oct 2017 18:43:49 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9IMhiVP031774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Oct 2017 18:43:47 -0400 Date: Wed, 18 Oct 2017 17:43:44 -0500 From: Benjamin Kaduk To: "WhiteWinterWolf (Simon)" Cc: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response Message-ID: <20171018224344.GA96685@kduck.kaduk.org> References: <32999.1508299211@segfault.tristatelogic.com> <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT19W8+TzS4FGTmkXPpidsFi3zbzNb vLr8is2B2WPGp/ksHvc3NTJ7/Ly6lj2AOYrLJiU1J7MstUjfLoErY9oq7oJjIhXnj+xha2Bc KtDFyMkhIWAice14F2MXIxeHkMBiJonGxb+hnI2MEv3TVrBCOFeZJLZMWM8K0sIioCox4cVm dhCbTUBFoqH7MjOILSLgKPHz/VawGmaBCInVJyazgNjCApYSs5vawep5gdb9e7QIzBYSKJM4 vuURG0RcUOLkzCcsEL06Eju33gGKcwDZ0hLL/3FAhOUlmrfOBlvFKeAucbNrKli5qICyxLx9 q9gmMArOQjJpFpJJsxAmzUIyaQEjyypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdU73czBK91JTS TYzgQHdR2sE48Z/XIUYBDkYlHt4F055HCrEmlhVX5h5ilORgUhLl1T3wLFKILyk/pTIjsTgj vqg0J7X4EKMEB7OSCK/2VqBy3pTEyqrUonyYlDQHi5I477agXZFCAumJJanZqakFqUUwWRkO DiUJ3s3XgRoFi1LTUyvSMnNKENJMHJwgw3mAhm+9BjK8uCAxtzgzHSJ/ilFRSpx3LUizAEgi ozQPrheUiCSy99e8YhQHekWYdz9IFQ8wicF1vwIazAQ0eJ3TE5DBJYkIKakGRin9C+k5Wfb5 U5+2VawP236i03b6YunfaRPmiHlsbp645tmajfL1oTLrI+681pt8lueq0uOLizVlA1nV1IUX vmHhT3eQj465oa0ZXhTBIi8jHRd/56POigMCbtuO/Zu4U/jgHxaFU0klx/p0Dm1c/bLP5u1c 1tKXxkezvjJ4nzc0jZhs7T27SomlOCPRUIu5qDgRAPnS9ucfAwAA 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: Wed, 18 Oct 2017 22:49:06 -0000 I fear I must wade into this thread, despite it being thick with FUD. On Wed, Oct 18, 2017 at 07:27:42PM +0200, WhiteWinterWolf (Simon) wrote: > Hi Ronald, > > Le 18/10/2017 à 06:00, Ronald F. Guilmette a écrit : > > > > In message <49252eda-3d48-f7bc-95e7-db716db4ed91@whitewinterwolf.com>, > > "WhiteWinterWolf (Simon)" wrote: > > > >> Ideally, you would use a specific protection for each of these layers, > >> so that an vulnerability affecting one layer would be compensated by > >> other layers. > > > > A good point. > > > > Right about now, I wish that I knew one hell of a lot more about both > > NFS and SMB than I do... and also SSH and TLS. I suspect that the > > file sharing protocols I am most concerned about (NFS & SMB) could > > perhaps be run in a manner such that both initial volume mounts and > > also data blocks (to & from) the share volumes would be additionally > > encrypted, so that I could be running everything securely, even if > > some attacker managed to do maximally evil things to my WiFi/WPA2 > > network. > > > > Do NFS and/or SMB have their own built-in encryption? > > No, not really. > > NFS has no built-in encryption, it may be possible to tunnel it but this > is out-of-scope here (using a VPN and tunnel everything would be easier > than nitpicking and tunnel only the NFS data flow). This statement is either false or highly misleading. NFS (both v3 and v4) is an RPC protocol, and RPCSEC_GSS exists and can provide per-message confidentiality protection. It may be true that Kerberos is basically the only GSS-API mechanism implemented for RPCSEC_GSS, and the necessary Kerberos setup is far more painful to set up than it needs to be, but all modern NFS implementations support it. > SMB has no widely compatible encryption: > > - Microsoft has built its own, proprietary encryption available and > compatible only with the latest Windows versions. > - Open source implementations rely on TLS, natively supported by some > client but requiring (AFAIK) `stunnel` server-side. I am not a SMB/CIFS expert, but (e.g.) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670508 seems to indicate that "proprietary" is false, and does not give much support to the claim that it requires TLS. (I believe in-kernel TLS support had not landed by June, when Xenial was getting its fix.) I am aware that this is a FreeBSD list and the offerings on FreeBSD for SMB are somewhat limited, but you did not scope your statement to FreeBSD and so neither do I. -Ben From owner-freebsd-security@freebsd.org Wed Oct 18 23:32:58 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 8800EE46A27 for ; Wed, 18 Oct 2017 23:32:58 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 52F056E5B9 for ; Wed, 18 Oct 2017 23:32:58 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1e4xpQ-0009os-A3; Thu, 19 Oct 2017 00:32:48 +0100 Date: Thu, 19 Oct 2017 00:32:48 +0100 From: Gary Palmer To: Benjamin Kaduk Cc: "WhiteWinterWolf (Simon)" , freebsd-security@freebsd.org, "Ronald F. Guilmette" Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response Message-ID: <20171018233248.GB96120@in-addr.com> References: <32999.1508299211@segfault.tristatelogic.com> <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> <20171018224344.GA96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171018224344.GA96685@kduck.kaduk.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false 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: Wed, 18 Oct 2017 23:32:58 -0000 On Wed, Oct 18, 2017 at 05:43:44PM -0500, Benjamin Kaduk wrote: > I fear I must wade into this thread, despite it being thick with FUD. > > On Wed, Oct 18, 2017 at 07:27:42PM +0200, WhiteWinterWolf (Simon) wrote: > > Hi Ronald, > > > > Le 18/10/2017 ? 06:00, Ronald F. Guilmette a ?crit : > > > > > > In message <49252eda-3d48-f7bc-95e7-db716db4ed91@whitewinterwolf.com>, > > > "WhiteWinterWolf (Simon)" wrote: > > > > > >> Ideally, you would use a specific protection for each of these layers, > > >> so that an vulnerability affecting one layer would be compensated by > > >> other layers. > > > > > > A good point. > > > > > > Right about now, I wish that I knew one hell of a lot more about both > > > NFS and SMB than I do... and also SSH and TLS. I suspect that the > > > file sharing protocols I am most concerned about (NFS & SMB) could > > > perhaps be run in a manner such that both initial volume mounts and > > > also data blocks (to & from) the share volumes would be additionally > > > encrypted, so that I could be running everything securely, even if > > > some attacker managed to do maximally evil things to my WiFi/WPA2 > > > network. > > > > > > Do NFS and/or SMB have their own built-in encryption? > > > > No, not really. > > > > NFS has no built-in encryption, it may be possible to tunnel it but this > > is out-of-scope here (using a VPN and tunnel everything would be easier > > than nitpicking and tunnel only the NFS data flow). > > This statement is either false or highly misleading. NFS (both v3 and v4) > is an RPC protocol, and RPCSEC_GSS exists and can provide per-message > confidentiality protection. It may be true that Kerberos is basically > the only GSS-API mechanism implemented for RPCSEC_GSS, and the necessary > Kerberos setup is far more painful to set up than it needs to be, > but all modern NFS implementations support it. More specifically, for FreeBSD a very quick search finds https://wiki.freebsd.org/KerberizedNFS which includes that you can configure an export as krb5p which encrypts the payload of RPC requests. Although the article is dated this year, "man mount_nfs" shows krb5p is documented in 10.3-RELEASE so all supported FBSD versions should implement krb5p. This is probably overkill for a home setup. Regards, Gary From owner-freebsd-security@freebsd.org Thu Oct 19 03:49:26 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 E2FFAE4E506 for ; Thu, 19 Oct 2017 03:49:26 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C483676E0A; Thu, 19 Oct 2017 03:49:26 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 945) id 24DF8C48A; Thu, 19 Oct 2017 03:49:26 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-17:07.wpa [REVISED] Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20171019034926.24DF8C48A@freefall.freebsd.org> Date: Thu, 19 Oct 2017 03:49:26 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 03:49:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-17:07.wpa Security Advisory The FreeBSD Project Topic: WPA2 protocol vulnerability Category: contrib Module: wpa Announced: 2017-10-16 Credits: Mathy Vanhoef Affects: All supported versions of FreeBSD. Corrected: 2017-10-17 17:30:18 UTC (stable/11, 11.1-STABLE) 2017-10-17 17:57:18 UTC (releng/11.1, 11.1-RELEASE-p2) 2017-10-17 17:56:03 UTC (releng/11.0, 11.0-RELEASE-p13) 2017-10-19 03:18:22 UTC (stable/10, 10.4-STABLE) 2017-10-19 03:20:17 UTC (releng/10.4, 10.4-RELEASE-p1) 2017-10-19 03:19:42 UTC (releng/10.3, 10.3-RELEASE-p22) CVE Name: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . 0. Revision history v1.0 2017-10-17 Initial release. v1.1 2017-10-19 Add patches for 10.x releases. I. Background Wi-Fi Protected Access II (WPA2) is a security protocol developed by the Wi-Fi Alliance to secure wireless computer networks. hostapd and wpa_supplicant are implementations of user space daemon for access points and wireless client that implements the WPA2 protocol. II. Problem Description A vulnerability was found in how a number of implementations can be triggered to reconfigure WPA/WPA2/RSN keys (TK, GTK, or IGTK) by replaying a specific frame that is used to manage the keys. III. Impact Such reinstallation of the encryption key can result in two different types of vulnerabilities: disabling replay protection and significantly reducing the security of encryption to the point of allowing frames to be decrypted or some parts of the keys to be determined by an attacker depending on which cipher is used. IV. Workaround An updated version of wpa_supplicant is available in the FreeBSD Ports Collection. Install version 2.6_2 or later of the security/wpa_supplicant port/pkg. Once installed, update /etc/rc.conf to use the new binary: wpa_supplicant_program="/usr/local/sbin/wpa_supplicant" and restart networking. An updated version of hostapd is available in the FreeBSD Ports Collection. Install version 2.6_1 or later of the net/hostapd port/pkg. Once installed, update /etc/rc.conf to use the new binary: hostapd_program="/usr/local/sbin/hostapd" and restart hostapd. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Restart the Wi-Fi network interfaces/hostapd or reboot the system. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install Restart the Wi-Fi network interfaces/hostapd or reboot the system. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 11.0-RELEASE, 11.1-RELEASE, and 11-STABLE] # fetch https://security.FreeBSD.org/patches/SA-17:07/wpa-11.patch # fetch https://security.FreeBSD.org/patches/SA-17:07/wpa-11.patch.asc # gpg --verify wpa-11.patch.asc [FreeBSD 10.3-RELEASE, 10.4-RELEASE, and 10-STABLE] # fetch https://security.FreeBSD.org/patches/SA-17:07/wpa-10.patch # fetch https://security.FreeBSD.org/patches/SA-17:07/wpa-10.patch.asc # gpg --verify wpa-10.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart the applicable daemons, or reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/11/ r324697 releng/11.0/ r324698 releng/11.1/ r324699 stable/10/ r324739 releng/10.3/ r324740 releng/10.4/ r324741 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEHPf/b631yp++G4yy7Wfs1l3PaucFAlnoGpNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDFD RjdGRjZGQURGNUNBOUZCRTFCOENCMkVENjdFQ0Q2NURDRjZBRTcACgkQ7Wfs1l3P auc7WBAAm27w+fujv5sJsRxauUMopTVtRh5utwbDuoHTP+L+RCWmQfVBmueNQ0gf uJzMNxBIkbtY9LvyukpRsH3iD7mh26c0pd9rxxkkr4F96C9B5+W0amxJF1gdm54/ F/50FpY+lo7cNs5tiBjypPrg8UOBBI/1G4XR7130XC0HjaTwt1ngZ0oQUWUMSsIp gN5ZfPul81WPWd1NqF+vyObcJhwq/Y1uoexoO27o7GQCFZoL3enZy8c4f1xqMlVM 4HHkTgNGac6E0aW+ArH4J0DFFAOJXPqF8rdt+9XINfoBbtliIyOixJ4oh1n6eAR0 VpBWZKFNyXSlUKIvDGa+LDhxgL1jJXV0ABSyKlUOijdmr3bbbiQE9MW/MNv2AFTd OAFQ0QQtm9KCWp5JLh+FPIb/kR2l7MOUP+yz4zFcJpdGtl9tDLyPN8vRTq60bY8O y7tBcf/SMqkd/AIFdchL4zrOguKnRARydIlwTarp8wtAQI3MKSsa1B0wgsDtlL6K xfdjnwWMKvKKlNOW16e1WXXO0n/ucHV4njBE+bGPro3jLgXP2/WFZpIGAR3I4xrr SdD4AxSNiR9f3bL7LRfMIbugJAylWNSlTLWUOVUv0/ONh85LqbcCj13NI230B64K ETx2QOZgKnCs2oDNiw4aQHb7kvi2w94Iw/R1sAPkkxYJWO3reyE= =h/5q -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Thu Oct 19 13:08:07 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 8434BE3AEE9 for ; Thu, 19 Oct 2017 13:08:07 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (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 50B4A68BEA for ; Thu, 19 Oct 2017 13:08:06 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) X-Originating-IP: 93.26.153.77 Received: from [10.137.2.15] (77.153.26.93.rev.sfr.net [93.26.153.77]) (Authenticated sender: lists@whitewinterwolf.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 73F7DC5A6A; Thu, 19 Oct 2017 15:07:58 +0200 (CEST) Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response To: Benjamin Kaduk Cc: "Ronald F. Guilmette" , freebsd-security@freebsd.org References: <32999.1508299211@segfault.tristatelogic.com> <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> <20171018224344.GA96685@kduck.kaduk.org> From: "WhiteWinterWolf (Simon)" Message-ID: Date: Thu, 19 Oct 2017 15:07:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171018224344.GA96685@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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, 19 Oct 2017 13:08:07 -0000 Hi Benjamin, Le 19/10/2017 à 00:43, Benjamin Kaduk a écrit : >> NFS has no built-in encryption, it may be possible to tunnel it but this >> is out-of-scope here (using a VPN and tunnel everything would be easier >> than nitpicking and tunnel only the NFS data flow). > > This statement is either false or highly misleading. NFS (both v3 and v4) > is an RPC protocol, and RPCSEC_GSS exists and can provide per-message > confidentiality protection. It may be true that Kerberos is basically > the only GSS-API mechanism implemented for RPCSEC_GSS, and the necessary > Kerberos setup is far more painful to set up than it needs to be, > but all modern NFS implementations support it. The support RPCSEC_GSS has been added in NFSv4, it was not available in NFSv3. Try to find any mention of RPCSEC_GSS in NFSv3 RFC: https://tools.ietf.org/html/rfc1813 NFSv4 RFC on the other side documents the addition of this feature in the protocol: https://tools.ietf.org/html/rfc3010 Don't confuse RPCSEC_GSS with AUTH_KERBEROS and AUTH_DES, which weren't widely supported and protect only the authentication phase: in-transit data was still left unprotected (and this is what we are talking about with this KRACK issue). The NFSv3 protocol itself had no authentication whatsoever, full trust was given to the client system, making it a blatant security hole in most infrastructures. That's precisely one of the reasons why NFSv4 was needed. I agree with you however that with a properly setup NFSv4 + Kerberos infrastructure you can get something secure. Granted. To go back in the realm of both FreeBSD and NAS appliances, it seems that FreeNAS supports NFSv4 "krb5p (authentication and privacy)": http://doc.freenas.org/9.3/freenas_sharing.html But NFSv3 is still the default even in the last version: http://doc.freenas.org/11/services.html I don't know if they managed to make it easy to use or if an external Kerberos server is required, but in the former case that would indeed be a great choice for end-users (but, given it is not the default and seems to be among the "advanced" options, I fear that setting-up Kerberos is left as an exercise for the user). >> SMB has no widely compatible encryption: >> >> - Microsoft has built its own, proprietary encryption available and >> compatible only with the latest Windows versions. >> - Open source implementations rely on TLS, natively supported by some >> client but requiring (AFAIK) `stunnel` server-side. > > I am not a SMB/CIFS expert, but (e.g.) > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670508 seems to > indicate that "proprietary" is false, and does not give much support > to the claim that it requires TLS. (I believe in-kernel TLS support > had not landed by June, when Xenial was getting its fix.) Sorry, but Microsoft SMB extensions *are* proprietary extensions. I encourage your to read the following page which explains the impressive work made by Samba people: https://www.samba.org/samba/docs/myths_about_samba.html And in particular the description of their "French cafe" technique: http://samba.org/ftp/tridge/misc/french_cafe.txt The Unix and Free/Libre software world owe them both for the SMB support on Unix made and maintained thanks for very hard and complex work, and as one of the most active defenders of the laws enforcing compatibility as an exception in vendor's EULA forbidding reverse engineering so other projects can legally build Free/Libre software compatible with closed-source proprietary software. Reducing Samba people work to simply coding some open standard is nearly disrespectful. Discussions have been made on documenting Microsoft's extensions as IETF standards, but Microsoft closed the subject years ago. In your link there is indeed mention of "upstream" development, but your link points toward an Ubuntu bug ticket and the "upstream" team is the Samba development team, not Microsoft. Due to security concern affecting in-transit data communicated in clear text, in 2008 Samba people developed an open extension allowing to provide good encryption: https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#idp62151568 As they state: "Currently this is only supported by Samba 3.2 smbclient, and hopefully soon Linux CIFSFS and MacOS/X clients. Windows clients do not support this feature." In 2012 Microsoft came with its own proprietary solution to achieve similar goal: https://blogs.technet.microsoft.com/filecab/2012/05/03/smb-3-security-enhancements-in-windows-server-2012/ Samba people now work to understand and reimplement Microsoft's own creation, but work is far from being complete ("in progress"): https://wiki.samba.org/index.php/SMB3_kernel_status#Security_Features An update of Samba documentation is pending which better explains the difference between Samba and Microsoft SMB encryption features, but this update is currently pending until, I suppose, that Microsoft SMB3 encryption support in Samba is complete: https://git.samba.org/?p=samba.git;a=commitdiff;h=51ae17b0703eaa481d602ffc7d8231a629fcb5fd Regarding TLS and SMB, I'm indeed sorry as Samba's implementation of SMB encryption (which is unrelated to the link you provided) indeed does not rely on it. I guess I mixed this with some documentation on how, thanks to `stunnel`, it is still possible to have an SMB encryption working for both Unix and Windows hosts: https://wiki.netbsd.org/tutorials/how_to_secure_samba_with_stunnel/ But the point in my previous answer was less about TLS than explaining that, as for now, there is no easy and widely compatible way to enable encryption for SMB, and therefore propose SFTP as the easiest, safest and most compatible alternative for low-tech end-users would the underlying network not be trustable. > I am aware that this is a FreeBSD list and the offerings on FreeBSD > for SMB are somewhat limited, but you did not scope your statement > to FreeBSD and so neither do I. And I'm happy about that. I like diversity, dislike blinkers and love to learn new things. Ronald brought on the table Linux (OpenElec), proprietary platforms (Amazon TV, Windows 7), and I think that's all fine because FreeBSD, "the power to serve", should also be able to serve to non-FreeBSD systems in a secure way, even when a vulnerability plagues the data-link network layer. > I fear I must wade into this thread, despite it being thick with FUD. We are on a technical mailing list targeting grown-up people, please remain focused on technical points and refrain from troll-like bold statements seeking pure confrontation and not making discussion progress in any way. Thank you for your comprehension. Thank you for your answer (except maybe the FUD thing, but that's already forgotten) as it was the occasion for me to check Samba work current status (it takes years but they are progressing and compatibility with current Windows infrastructure is reaching the horizon, yes!) and remind to myself about the FreeNAS project which I still have to try myself. Regards, Simon. -- WhiteWinterWolf https://www.whitewinterwolf.com From owner-freebsd-security@freebsd.org Thu Oct 19 13:37:42 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 8EF68E3BC9E for ; Thu, 19 Oct 2017 13:37:42 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (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 5DFFE6A37A for ; Thu, 19 Oct 2017 13:37:42 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) X-Originating-IP: 93.26.153.77 Received: from [10.137.2.15] (77.153.26.93.rev.sfr.net [93.26.153.77]) (Authenticated sender: lists@whitewinterwolf.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id E6B4BC5A50; Thu, 19 Oct 2017 15:37:40 +0200 (CEST) Subject: Re: freebsd-security Digest, Vol 634, Issue 3 To: Walter Parker , freebsd-security@freebsd.org References: From: "WhiteWinterWolf (Simon)" Message-ID: <26ffd1eb-d8c2-0fdd-da38-b9e3790144ad@whitewinterwolf.com> Date: Thu, 19 Oct 2017 15:37:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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, 19 Oct 2017 13:37:42 -0000 Hi Walter, Le 18/10/2017 à 22:52, Walter Parker a écrit : > SMB has supported authentication signing for a long time (more than a > decade). That can be used for basic security. > SMB3 supports encryption. To work with SMB3 encryption you will need > at least Windows 8. > The Samba project supports SMB3 and many of the security features in > it, but not share level encryption. Password authentication works with > signing and encryption. Until Samba supports the new share encryption > in SMB3, you will need to use something like stunnel (or an encrypted > VPN) to enable the privacy features that come with encryption. > > What that means is that the newest versions of Samba can talk to newer > Windows boxes with the authentication pieces (the username/password > exchange) done with encryption to make exploitation much harder. I agree with you. However, puts it in the context: the current thread is a malicious user acting as man-in-the-middle between a user and a server storing potentially sensitive files (as I said in my previous answers, for non-sensitive files such as media files a read-only SMB/NFS/whatever is perfectly fine). The threat here is not someone attempting to login to the file server. In this case, end-to-end encryption seems required to me (I don't want the content of personal or business-related documents to fall in wrong hands). As a side note, it may worth to highlight that Samba actually offered SMB encryption *before* Microsoft, but Microsoft preferred to create its own solution that Samba must now copy. All details can be found in my answer to Benjamin in the the same thread. In this case, for a low-tech people, I would tend to suggest using SFTP (a password-based access is enough) instead of a stunneled SMB share as I personally find it is easier to setup and more efficient. > Encryption on NFS appears to be by using stunnel or SSH to encrypt the > data (or using a VPN). Regarding NFS, Benjamin and Gary rightly highlighted that NFSv4 supports end-to-end authentication and encryption and is suitable for use over untrusted networks. However, I don't know if end-users' (and in particular Ronald's) NAS offers any easy-to-use NFSv4 feature. If this is the case, this is indeed a very interesting choice based purely on open standards, but I fear that there is no such feature which leaves us again with SFTP. Regards, Simon. -- WhiteWinterWolf https://www.whitewinterwolf.com From owner-freebsd-security@freebsd.org Thu Oct 19 16:07:21 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 8772CE3F44A for ; Thu, 19 Oct 2017 16:07:21 +0000 (UTC) (envelope-from joey@joeykelly.net) Received: from safegreet.com (safegreet.com [173.230.129.132]) (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 621406F0B3 for ; Thu, 19 Oct 2017 16:07:21 +0000 (UTC) (envelope-from joey@joeykelly.net) Received: from localhost (localhost [127.0.0.1]) by safegreet.com (Postfix) with ESMTP id 5B84C4357 for ; Thu, 19 Oct 2017 10:59:42 -0500 (CDT) X-Virus-Scanned: amavisd-new at safegreet.com Received: from safegreet.com ([127.0.0.1]) by localhost (safegreet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cgSTYnqktOmU for ; Thu, 19 Oct 2017 10:59:41 -0500 (CDT) Received: from freechin.atlnet (47-44-49-2.static.unas.mo.charter.com [47.44.49.2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by safegreet.com (Postfix) with ESMTPSA id 55C8F42D7 for ; Thu, 19 Oct 2017 10:59:41 -0500 (CDT) From: Joey Kelly To: freebsd-security@freebsd.org Subject: Re: freebsd-security Digest, Vol 634, Issue 3 Date: Thu, 19 Oct 2017 11:59:40 -0400 Message-ID: <1511621.jdgZNmovq9@freechin.atlnet> User-Agent: KMail/4.14.10 (FreeBSD/11.0-RELEASE-p12; KDE/4.14.30; amd64; ; ) In-Reply-To: <26ffd1eb-d8c2-0fdd-da38-b9e3790144ad@whitewinterwolf.com> References: <26ffd1eb-d8c2-0fdd-da38-b9e3790144ad@whitewinterwolf.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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, 19 Oct 2017 16:07:21 -0000 > > In this case, for a low-tech people, I would tend to suggest using SFTP > (a password-based access is enough) instead of a stunneled SMB share as > I personally find it is easier to setup and more efficient. If you have an ssh server (if you have FreeBSD, you have one), that will function as a SFTP or SCP server. Put it on an alternative port if possible, and for the client end, use WinSCP, Fugu on a Mac (I think it's Fugu..), and for BSD/Linux/smartphones you have any number of client apps to choose from. Easy peasy, a familiar 2-pane GUI FTP layout, very secure. -- Joey Kelly Minister of the Gospel and Linux Consultant http://joeykelly.net 504-239-6550 From owner-freebsd-security@freebsd.org Fri Oct 20 02:14:44 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 2F307E4CE5B for ; Fri, 20 Oct 2017 02:14:44 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 B996C636C0 for ; Fri, 20 Oct 2017 02:14:43 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-5c1ff70000004cba-d7-59e95c08ce1b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id F0.18.19642.90C59E95; Thu, 19 Oct 2017 22:14:33 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9K2EVeW016249; Thu, 19 Oct 2017 22:14:31 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9K2ER61018797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2017 22:14:29 -0400 Date: Thu, 19 Oct 2017 21:14:27 -0500 From: Benjamin Kaduk To: "WhiteWinterWolf (Simon)" Cc: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response Message-ID: <20171020021427.GH96685@kduck.kaduk.org> References: <32999.1508299211@segfault.tristatelogic.com> <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> <20171018224344.GA96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR4hTV1uWMeRlp0LRNw6Jn0xM2i5b5t5kt Xl1+xebA7DHj03wWj/ubGpk9fl5dyx7AHMVlk5Kak1mWWqRvl8CVsa9FquC3TMWyWf/ZGxhn iXcxcnJICJhIrLo9ia2LkYtDSGAxk8TJ+x+ZIZyNjBK7/19kB6kSErjKJLG+N62LkYODRUBV 4vxnI5Awm4CKREP3ZWYQW0TAUeLn+62sIDazQITE6hOTWUBsYQFLidlN7WBjeIGWTZv6kR1i /j1Gia/tNxkhEoISJ2c+YYFo1pHYufUOG8guZgFpieX/OCDC8hLNW2eD7eIUcJd4P+UiG4gt KqAsMW/fKrYJjIKzkEyahWTSLIRJs5BMWsDIsopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83 s0QvNaV0EyMozNldlHYwTvzndYhRgINRiYd3w4UXkUKsiWXFlbmHGCU5mJREeTdwvIwU4kvK T6nMSCzOiC8qzUktPsQowcGsJML7Igwox5uSWFmVWpQPk5LmYFES590WtCtSSCA9sSQ1OzW1 ILUIJivDwaEkwZsbDdQoWJSanlqRlplTgpBm4uAEGc4DNNwTpIa3uCAxtzgzHSJ/ilFRSpzX IQooIQCSyCjNg+sFpSGJ7P01rxjFgV4R5q0EaecBpjC47ldAg5mABrPbvwAZXJKIkJJqYJyn FlMns3uaVfdilV9+5ja6J6e+d1ETjup23O73Pb9S+/b+6zW9eoJnf3k42ojuYWZ04el1/Wl1 4HHtY5fXOx7E+a1e5D3P51eisv5CEf26S0t27KyztDExSshcz71EROeVr1ed+rVfJQru9oVl FXqvjGpaV9U+3h4f8f5TxsO/09XMD+9KVWIpzkg01GIuKk4EANywKwAeAwAA 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: Fri, 20 Oct 2017 02:14:44 -0000 On Thu, Oct 19, 2017 at 03:07:57PM +0200, WhiteWinterWolf (Simon) wrote: > Hi Benjamin, > > Le 19/10/2017 à 00:43, Benjamin Kaduk a écrit : > >> NFS has no built-in encryption, it may be possible to tunnel it but this > >> is out-of-scope here (using a VPN and tunnel everything would be easier > >> than nitpicking and tunnel only the NFS data flow). > > > > This statement is either false or highly misleading. NFS (both v3 and v4) > > is an RPC protocol, and RPCSEC_GSS exists and can provide per-message > > confidentiality protection. It may be true that Kerberos is basically > > the only GSS-API mechanism implemented for RPCSEC_GSS, and the necessary > > Kerberos setup is far more painful to set up than it needs to be, > > but all modern NFS implementations support it. > > The support RPCSEC_GSS has been added in NFSv4, it was not available in > NFSv3. > > Try to find any mention of RPCSEC_GSS in NFSv3 RFC: > https://tools.ietf.org/html/rfc1813 > > NFSv4 RFC on the other side documents the addition of this feature in > the protocol: > https://tools.ietf.org/html/rfc3010 Right, NFSv4 built it in from the start whereas it had to be hacked onto NFSv3 > Don't confuse RPCSEC_GSS with AUTH_KERBEROS and AUTH_DES, which weren't > widely supported and protect only the authentication phase: in-transit > data was still left unprotected (and this is what we are talking about > with this KRACK issue). It seems that RFC 2623 aims to clarify their differences. (It only covers the single-DES kerberos enctypes, which are not particularly secure anymore; see RFC 6649.) > The NFSv3 protocol itself had no authentication whatsoever, full trust > was given to the client system, making it a blatant security hole in > most infrastructures. That's precisely one of the reasons why NFSv4 was > needed. Indeed, the design goals were from a different era (and before my time). > I don't know if they managed to make it easy to use or if an external > Kerberos server is required, but in the former case that would indeed be > a great choice for end-users (but, given it is not the default and seems > to be among the "advanced" options, I fear that setting-up Kerberos is > left as an exercise for the user). Alas, it is left that way all too often. Since we're on the topic, I'll link http://web.mit.edu/kerberos/krb5-latest/doc/admin/install.html and note that that is quite different from the Heimdal included in the FreeBSD base system. > > >> SMB has no widely compatible encryption: > >> > >> - Microsoft has built its own, proprietary encryption available and > >> compatible only with the latest Windows versions. > >> - Open source implementations rely on TLS, natively supported by some > >> client but requiring (AFAIK) `stunnel` server-side. > > > > I am not a SMB/CIFS expert, but (e.g.) > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670508 seems to > > indicate that "proprietary" is false, and does not give much support > > to the claim that it requires TLS. (I believe in-kernel TLS support > > had not landed by June, when Xenial was getting its fix.) > > Sorry, but Microsoft SMB extensions *are* proprietary extensions. > > I encourage your to read the following page which explains the > impressive work made by Samba people: > > https://www.samba.org/samba/docs/myths_about_samba.html > > And in particular the description of their "French cafe" technique: > > http://samba.org/ftp/tridge/misc/french_cafe.txt Fair enough, and thank you for the links. I don't do much with SMB, myself, so had to try to search while writing my previous mail. -Ben From owner-freebsd-security@freebsd.org Fri Oct 20 15:35:39 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 D3EA9E38EF2 for ; Fri, 20 Oct 2017 15:35:39 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (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 A19E17FEF2 for ; Fri, 20 Oct 2017 15:35:39 +0000 (UTC) (envelope-from freebsd.lists@whitewinterwolf.com) X-Originating-IP: 93.26.153.77 Received: from [10.137.2.15] (77.153.26.93.rev.sfr.net [93.26.153.77]) (Authenticated sender: lists@whitewinterwolf.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id D6E4741C07D; Fri, 20 Oct 2017 17:35:29 +0200 (CEST) Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response To: Benjamin Kaduk Cc: "Ronald F. Guilmette" , freebsd-security@freebsd.org References: <32999.1508299211@segfault.tristatelogic.com> <53010303-bd65-26a1-64b9-6eefa325ca46@whitewinterwolf.com> <20171018224344.GA96685@kduck.kaduk.org> <20171020021427.GH96685@kduck.kaduk.org> From: "WhiteWinterWolf (Simon)" Message-ID: Date: Fri, 20 Oct 2017 17:35:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171020021427.GH96685@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Fri, 20 Oct 2017 15:35:39 -0000 Hi Benjamin, Le 20/10/2017 à 04:14, Benjamin Kaduk a écrit : > Alas, it is left that way all too often. Since we're on the topic, I'll link > http://web.mit.edu/kerberos/krb5-latest/doc/admin/install.html > and note that that is quite different from the Heimdal included in the > FreeBSD base system. Thank you for the link! > Fair enough, and thank you for the links. I don't do much with SMB, myself, > so had to try to search while writing my previous mail. And on my side I'm more used to SMB, not for Windows compatibility but simply because of NFS3 limitations but you convinced me to put my nose again in the NFS world and look closer to NFS4 :). Thanks, Simon. -- WhiteWinterWolf https://www.whitewinterwolf.com