From owner-freebsd-security@freebsd.org Sun Apr 9 14:40:12 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 7A0EDD3661E; Sun, 9 Apr 2017 14:40:12 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF8417D; Sun, 9 Apr 2017 14:40:12 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.205] (unknown [172.16.0.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B1EF8186E; Sun, 9 Apr 2017 14:40:11 +0000 (UTC) Subject: Re: Proposal for a design for signed kernel/modules/etc To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> From: Eric McCorkle Message-ID: <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> Date: Sun, 9 Apr 2017 10:40:07 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170408115222.GA64207@brick> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mtArbQXOnqfKwxkx45JFK13QqcR6Jn47r" 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: Sun, 09 Apr 2017 14:40:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mtArbQXOnqfKwxkx45JFK13QqcR6Jn47r Content-Type: multipart/mixed; boundary="LRivelBAQdLMTNuKBGmlcXn2bavWRRppf"; protected-headers="v1" From: Eric McCorkle To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Message-ID: <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> In-Reply-To: <20170408115222.GA64207@brick> --LRivelBAQdLMTNuKBGmlcXn2bavWRRppf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/08/2017 07:52, Edward Tomasz Napiera=C5=82a wrote: > On 0408T0803, Eric McCorkle wrote: >> On 04/08/2017 07:11, Edward Tomasz Napiera=C5=82a wrote: >>> On 0327T1354, Eric McCorkle wrote: >>>> Hello everyone, >>>> >>>> The following is a design proposal for signed kernel and kernel modu= le >>>> loading, both at boot- and runtime (with the possibility open for si= gned >>>> executables and libraries if someone wanted to go that route). I'm >>>> interested in feedback on the idea before I start actually writing c= ode >>>> for it. >>> >>> I see two potential problems with this. >>> >>> First, our current loader(8) depends heavily on Forth code. By makin= g >>> it load modified 4th files, you can do absolutely anything you want; >>> AFAIK they have unrestricted access to hardware. So you should prefe= rably >>> be able to sign them as well. You _might_ (not sure on this one) als= o >>> want to be able to restrict access to some of the loader configuratio= n >>> variables. >> >> Loader is handled by the UEFI secure boot framework, though the concer= ns >> about the 4th code are still valid. In a secure system, you'd want to= >> do something about that, but the concerns are different enough (and it= 's >> isolated enough) that it could be done separately. >=20 > Unless the way to address those ends up being a signature mechanism > that doesn't depend on the format of the files being signed. I explored the idea of wrapped or detached signatures in the previous discussion. Envelopes or detached signatures could make sense for the 4th files. It's a small, obscure set of code that probably isn't changed very often. Envelopes or detached signatures for kernel modules and especially signed executables and libraries both have extensive, far-reaching consequences for system administration, packaging, tooling, the ports collection, and so on, whereas signing the executable with an additional section has no such consequences. Config files (and the 4th files really are more like config files) have a different set of constraints, and detached signatures are probably the way to go there. So loader should probably support detached PKCS#7 signature checks. --LRivelBAQdLMTNuKBGmlcXn2bavWRRppf-- --mtArbQXOnqfKwxkx45JFK13QqcR6Jn47r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRELMWN3SgpoYkrmidWwohAqoAEjQUCWOpHyAAKCRBWwohAqoAE jT0zAQCjaQTkFbS5xkr4eixhwOysahTZRg1iKojdfj/NpbIwyQEAj8MuUJvPSi12 xIqgCFSa47WyfCEAoAMOcjMqwdSEpgs= =i63w -----END PGP SIGNATURE----- --mtArbQXOnqfKwxkx45JFK13QqcR6Jn47r-- From owner-freebsd-security@freebsd.org Sun Apr 9 16:01:46 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 D02ACD3688F; Sun, 9 Apr 2017 16:01:46 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 9A58CCD2; Sun, 9 Apr 2017 16:01:46 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.205] (unknown [172.16.0.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 1E01A189B; Sun, 9 Apr 2017 16:01:46 +0000 (UTC) Subject: Re: Proposal for a design for signed kernel/modules/etc To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> <20170409155240.GA18363@brick> From: Eric McCorkle Message-ID: <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> Date: Sun, 9 Apr 2017 12:01:42 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170409155240.GA18363@brick> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O4gwvhcQpw7ukKHrkL2c3DUgq5CLSkPG4" 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: Sun, 09 Apr 2017 16:01:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O4gwvhcQpw7ukKHrkL2c3DUgq5CLSkPG4 Content-Type: multipart/mixed; boundary="P2CjpF9BIF78trnltNW12bP2AkfCfbv8U"; protected-headers="v1" From: Eric McCorkle To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Message-ID: <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> <20170409155240.GA18363@brick> In-Reply-To: <20170409155240.GA18363@brick> --P2CjpF9BIF78trnltNW12bP2AkfCfbv8U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/09/2017 11:52, Edward Tomasz Napiera=C5=82a wrote: > On 0409T1040, Eric McCorkle wrote: >> On 04/08/2017 07:52, Edward Tomasz Napiera=C5=82a wrote: >>> On 0408T0803, Eric McCorkle wrote: >>>> On 04/08/2017 07:11, Edward Tomasz Napiera=C5=82a wrote: >>>>> On 0327T1354, Eric McCorkle wrote: >>>>>> Hello everyone, >>>>>> >>>>>> The following is a design proposal for signed kernel and kernel mo= dule >>>>>> loading, both at boot- and runtime (with the possibility open for = signed >>>>>> executables and libraries if someone wanted to go that route). I'= m >>>>>> interested in feedback on the idea before I start actually writing= code >>>>>> for it. >>>>> >>>>> I see two potential problems with this. >>>>> >>>>> First, our current loader(8) depends heavily on Forth code. By mak= ing >>>>> it load modified 4th files, you can do absolutely anything you want= ; >>>>> AFAIK they have unrestricted access to hardware. So you should pre= ferably >>>>> be able to sign them as well. You _might_ (not sure on this one) a= lso >>>>> want to be able to restrict access to some of the loader configurat= ion >>>>> variables. >>>> >>>> Loader is handled by the UEFI secure boot framework, though the conc= erns >>>> about the 4th code are still valid. In a secure system, you'd want = to >>>> do something about that, but the concerns are different enough (and = it's >>>> isolated enough) that it could be done separately. >>> >>> Unless the way to address those ends up being a signature mechanism >>> that doesn't depend on the format of the files being signed. >> >> I explored the idea of wrapped or detached signatures in the previous >> discussion. Envelopes or detached signatures could make sense for the= >> 4th files. It's a small, obscure set of code that probably isn't >> changed very often. >> >> Envelopes or detached signatures for kernel modules and especially >> signed executables and libraries both have extensive, far-reaching >> consequences for system administration, packaging, tooling, the ports >> collection, and so on, whereas signing the executable with an addition= al >> section has no such consequences. >> >> Config files (and the 4th files really are more like config files) hav= e >> a different set of constraints, and detached signatures are probably t= he >> way to go there. So loader should probably support detached PKCS#7 >> signature checks. >=20 > The third way that might be worth considering would be to just append > the signature. This would work for both 4th (if you prepend it with > whatever is the 4th comment character) and ELF, without the need for > changing or extending either format. No, that won't work at all. That's going to break the tooling for ELF files as well as applications that use them, and it won't work for any configuration file aside from loader.4th It wouldn't even work for boot.conf, for example. More generally, that's basing an entire standard off a dead language that's used in only one place, and in a way the precludes compatibility with any file format that uses a different comment character. It also mandates some kind of ASCII encoding scheme to avoid newlines. If I was going to adopt a solution that broke existing tooling, I'd at least go with a proper envelope scheme. --P2CjpF9BIF78trnltNW12bP2AkfCfbv8U-- --O4gwvhcQpw7ukKHrkL2c3DUgq5CLSkPG4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRELMWN3SgpoYkrmidWwohAqoAEjQUCWOpa5gAKCRBWwohAqoAE jWZbAP4iE8lRz6j0hwlRq4UEs8FRld4Okk4KzkmhwOJ4Wm8Z7QD+KTupXfPRXknm 6S8BLi6wyH1kgDDmwp8CGw/iQTv66Q8= =EaXS -----END PGP SIGNATURE----- --O4gwvhcQpw7ukKHrkL2c3DUgq5CLSkPG4-- From owner-freebsd-security@freebsd.org Sun Apr 9 17:17:37 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 5BB91D3601E; Sun, 9 Apr 2017 17:17:37 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 2C2459CD; Sun, 9 Apr 2017 17:17:37 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.205] (unknown [172.16.0.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id A712318CF; Sun, 9 Apr 2017 17:17:29 +0000 (UTC) Subject: Re: Proposal for a design for signed kernel/modules/etc To: Warner Losh References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> <20170409155240.GA18363@brick> <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org From: Eric McCorkle Message-ID: <082223a0-1768-f5f0-9f4a-2e9fd45716c7@metricspace.net> Date: Sun, 9 Apr 2017 13:17:26 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MKJ6xGh0nJg9jVG0lQanCjkQ11rg9qNAe" 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: Sun, 09 Apr 2017 17:17:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MKJ6xGh0nJg9jVG0lQanCjkQ11rg9qNAe Content-Type: multipart/mixed; boundary="CL7dlJ1GfWJTi96v7o8i4fBVIpSo8E8P3"; protected-headers="v1" From: Eric McCorkle To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Message-ID: <082223a0-1768-f5f0-9f4a-2e9fd45716c7@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> <20170409155240.GA18363@brick> <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> In-Reply-To: --CL7dlJ1GfWJTi96v7o8i4fBVIpSo8E8P3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/09/2017 12:50, Warner Losh wrote: > On Sun, Apr 9, 2017 at 10:01 AM, Eric McCorkle w= rote: >> On 04/09/2017 11:52, Edward Tomasz Napiera=C5=82a wrote: >>> On 0409T1040, Eric McCorkle wrote: >>>> On 04/08/2017 07:52, Edward Tomasz Napiera=C5=82a wrote: >>>>> On 0408T0803, Eric McCorkle wrote: >>>>>> On 04/08/2017 07:11, Edward Tomasz Napiera=C5=82a wrote: >>>>>>> On 0327T1354, Eric McCorkle wrote: >>>>>>>> Hello everyone, >>>>>>>> >>>>>>>> The following is a design proposal for signed kernel and kernel = module >>>>>>>> loading, both at boot- and runtime (with the possibility open fo= r signed >>>>>>>> executables and libraries if someone wanted to go that route). = I'm >>>>>>>> interested in feedback on the idea before I start actually writi= ng code >>>>>>>> for it. >>>>>>> >>>>>>> I see two potential problems with this. >>>>>>> >>>>>>> First, our current loader(8) depends heavily on Forth code. By m= aking >>>>>>> it load modified 4th files, you can do absolutely anything you wa= nt; >>>>>>> AFAIK they have unrestricted access to hardware. So you should p= referably >>>>>>> be able to sign them as well. You _might_ (not sure on this one)= also >>>>>>> want to be able to restrict access to some of the loader configur= ation >>>>>>> variables. >>>>>> >>>>>> Loader is handled by the UEFI secure boot framework, though the co= ncerns >>>>>> about the 4th code are still valid. In a secure system, you'd wan= t to >>>>>> do something about that, but the concerns are different enough (an= d it's >>>>>> isolated enough) that it could be done separately. >>>>> >>>>> Unless the way to address those ends up being a signature mechanism= >>>>> that doesn't depend on the format of the files being signed. >>>> >>>> I explored the idea of wrapped or detached signatures in the previou= s >>>> discussion. Envelopes or detached signatures could make sense for t= he >>>> 4th files. It's a small, obscure set of code that probably isn't >>>> changed very often. >>>> >>>> Envelopes or detached signatures for kernel modules and especially >>>> signed executables and libraries both have extensive, far-reaching >>>> consequences for system administration, packaging, tooling, the port= s >>>> collection, and so on, whereas signing the executable with an additi= onal >>>> section has no such consequences. >>>> >>>> Config files (and the 4th files really are more like config files) h= ave >>>> a different set of constraints, and detached signatures are probably= the >>>> way to go there. So loader should probably support detached PKCS#7 >>>> signature checks. >>> >>> The third way that might be worth considering would be to just append= >>> the signature. This would work for both 4th (if you prepend it with >>> whatever is the 4th comment character) and ELF, without the need for >>> changing or extending either format. >> >> No, that won't work at all. That's going to break the tooling for ELF= >> files as well as applications that use them, and it won't work for any= >> configuration file aside from loader.4th It wouldn't even work for >> boot.conf, for example. >> >> More generally, that's basing an entire standard off a dead language >> that's used in only one place, and in a way the precludes compatibilit= y >> with any file format that uses a different comment character. It also= >> mandates some kind of ASCII encoding scheme to avoid newlines. >=20 > You don't need to avoid new lines with 4th. It doesn't even need to be > an ASCII encoding scheme, unless you are doing something crazy like > trying to push the signature through the 4th parser, which is nuts. > Forth can read binary files just fine. But I think arguing over the > 4th stuff is a distraction, dee below. >=20 >> If I was going to adopt a solution that broke existing tooling, I'd at= >> least go with a proper envelope scheme. >=20 > That would be preferable. >=20 > But why the either-or dichotomy? Seems like you're looking at the > problem wrong if you are arguing about 4th code. You should be > thinking more in terms of, at most, a couple of 4th words that can > implement this stuff (so the loader could show that the kernel is > signed and valid vs is not signed vs is signed, but the signature is > bogus). 99% of the functionality should be in C, and should be > sharable between the loader, the kernel and whatever else may wish to > verify signatures before loading. It would also allow the same > functionality to be pushed into the on-again-off-again LUA boot > project (which seems to have momentum this time). >=20 I'm not following what you're saying. I don't think anyone was suggesting doing signature *verification* in 4th (at least I hope not!). The issue is about the format of the signatures. Basically, the crux of my proposal is about using an ELF section to store signatures, which has immediate use for kernel module loading as well as in the boot loader for the same purpose. Now, the boot programs, loader, and perhaps the kernel too all load various additional config files (boot.conf, loader.4th, loader.conf, etc). These do also need to be signed, so there needs to be a solution for this as well. There's significant advantages to the ELF .sign section, and all the alternatives have serious disadvantages. For these reasons, I'm pretty set on the .sign section. With the config files (which includes the 4th code), you don't have a file format that transparently supports additional metadata (like ELF does). So you have a choice between storing detached signatures in an external file (the way GRUB does) or using an envelope format. Of the two, the envelope is preferable, I think, though it should probably have a different name (ex: loader.4th.pk7, loader.conf.pk7) and be understood to contain an envelope, not a raw config file. The implementation of all this would be in C, of course. The verification stuff would be compiled in to loader and kernel. The elf-signing would be done by a command-line utility (which I've half-written at this point). Ideally, the signing of config files would be doable with the standard openssl command-line. --CL7dlJ1GfWJTi96v7o8i4fBVIpSo8E8P3-- --MKJ6xGh0nJg9jVG0lQanCjkQ11rg9qNAe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRELMWN3SgpoYkrmidWwohAqoAEjQUCWOpspgAKCRBWwohAqoAE jQ38AQCBS/XagV7XTbcddwhcVSvvwPw1iQKYnMYAUUumSSJ9ZQD/ahJsW5QVbf7R d8z+nk1a4SUI98zbv4crR0O+pXjHSgE= =BuYb -----END PGP SIGNATURE----- --MKJ6xGh0nJg9jVG0lQanCjkQ11rg9qNAe-- From owner-freebsd-security@freebsd.org Sun Apr 9 15:52:45 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 6378AD3642C; Sun, 9 Apr 2017 15:52:45 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 E00DC370; Sun, 9 Apr 2017 15:52:44 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id t189so21549268wmt.1; Sun, 09 Apr 2017 08:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=cSWNPRDYzpXGgut0TcmsMKgHX9IWDb8BS4PWSe4Bwrw=; b=d+XCugcs4eR/vvrYVnu2s8AMj4oCtvs8SlCR/PjpqarV7L9pGpe8ISWF3NxMME7Xar E/xg/MGw9d1P9O8Qm7DRZ4oR5uV6rXmYwbF8+oMrIofSBaIB/s9skvcSKZiQwVVMs4/7 bTx/EXcc2akVr64wmdJIj3vDnDmk6Dm/iPCYqsrQxjbGIbK0fpsRw2uDWZOrcyUCYdCi caefe7TtRMXx8bjDg2d05/PO04X/beUpMhi+Cf6gSHB/It/m0mc/y7P3s0RM6RNxb2q9 SebnWXt2osiNi9Coa83Q3NZXt9fH5YSc77MrTc0NZL1ejYFVQSlmmwtkw1ozJQ/iIp2y DrBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=cSWNPRDYzpXGgut0TcmsMKgHX9IWDb8BS4PWSe4Bwrw=; b=f96PP7XQuGTIM6Sb+omP1tmo/ytWysmcJ+pEiElt7HiJDcNvkPNf2+CDVotrPl/V35 rmtytIqBHxn+OxUNxNGDcL1Q/C2S87Hlv/5rUolLZh1LDWmolcKzX37qgftIj7yK1GAd iEJXe2GOnuW79DbaadBqpWyBNmAFTANYecjc1FiKRrivf8q8Xcj/WL5keDSVHXptwmjV ttTtZbyIk2tSJjFzdTcdyEpn8gKkoEW+iGRPjjcBhONQE7RMYr+9hK2fMe/ZIsV1AtJQ 3HDEAtVS7KP4a9ypFzplB+mu0qt6agiA7H7aGkFLsAxJ/A1soPtH+qlsB2WkVktpdkRX JdVg== X-Gm-Message-State: AN3rC/49buf3i1xQMGn6u86ZX/cq55QDm863joY2x9oMXvZgbM7ikqgK SS95vJU8tHE7p/gk X-Received: by 10.28.90.2 with SMTP id o2mr6544309wmb.53.1491753162403; Sun, 09 Apr 2017 08:52:42 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id v186sm6809403wmv.2.2017.04.09.08.52.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Apr 2017 08:52:41 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 9 Apr 2017 16:52:40 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Subject: Re: Proposal for a design for signed kernel/modules/etc Message-ID: <20170409155240.GA18363@brick> Mail-Followup-To: Eric McCorkle , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> User-Agent: Mutt/1.8.0 (2017-02-23) X-Mailman-Approved-At: Sun, 09 Apr 2017 19:44:03 +0000 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: Sun, 09 Apr 2017 15:52:45 -0000 On 0409T1040, Eric McCorkle wrote: > On 04/08/2017 07:52, Edward Tomasz Napierała wrote: > > On 0408T0803, Eric McCorkle wrote: > >> On 04/08/2017 07:11, Edward Tomasz Napierała wrote: > >>> On 0327T1354, Eric McCorkle wrote: > >>>> Hello everyone, > >>>> > >>>> The following is a design proposal for signed kernel and kernel module > >>>> loading, both at boot- and runtime (with the possibility open for signed > >>>> executables and libraries if someone wanted to go that route). I'm > >>>> interested in feedback on the idea before I start actually writing code > >>>> for it. > >>> > >>> I see two potential problems with this. > >>> > >>> First, our current loader(8) depends heavily on Forth code. By making > >>> it load modified 4th files, you can do absolutely anything you want; > >>> AFAIK they have unrestricted access to hardware. So you should preferably > >>> be able to sign them as well. You _might_ (not sure on this one) also > >>> want to be able to restrict access to some of the loader configuration > >>> variables. > >> > >> Loader is handled by the UEFI secure boot framework, though the concerns > >> about the 4th code are still valid. In a secure system, you'd want to > >> do something about that, but the concerns are different enough (and it's > >> isolated enough) that it could be done separately. > > > > Unless the way to address those ends up being a signature mechanism > > that doesn't depend on the format of the files being signed. > > I explored the idea of wrapped or detached signatures in the previous > discussion. Envelopes or detached signatures could make sense for the > 4th files. It's a small, obscure set of code that probably isn't > changed very often. > > Envelopes or detached signatures for kernel modules and especially > signed executables and libraries both have extensive, far-reaching > consequences for system administration, packaging, tooling, the ports > collection, and so on, whereas signing the executable with an additional > section has no such consequences. > > Config files (and the 4th files really are more like config files) have > a different set of constraints, and detached signatures are probably the > way to go there. So loader should probably support detached PKCS#7 > signature checks. The third way that might be worth considering would be to just append the signature. This would work for both 4th (if you prepend it with whatever is the 4th comment character) and ELF, without the need for changing or extending either format. From owner-freebsd-security@freebsd.org Sun Apr 9 16:50: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 9A3A3D365D4 for ; Sun, 9 Apr 2017 16:50:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 60ABF78D for ; Sun, 9 Apr 2017 16:50:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id l7so71989506ioe.3 for ; Sun, 09 Apr 2017 09:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=uq4N62VcObOpr6hm1+yt24jW5Lh4EG5i+bJ9+JSrzn8=; b=Yy8+Q7CiyFdr9jOo5b0lcI6gWUdlae3qFXQgXDEpw7wne6mSQPVMBpmATDg579XYDu 5S6axvlm+TyNFVZhLr/N0pmR0UYF3DQHgYy33nW9Wh6fQ5Htwhw8oBm3FClQPMAs74R3 BQeK2ADJtQr2PHMkndIFAg3xO1zP/H5l7fGcWjRdDRbsSl6HVeQIOI3f8JygKMCRTwGV 3M5PjZ8itgU0ufL7UvkEVFWaXuM4yxl71UZR5AzGElQlNbhfZcqglKTapItY31miP7+L DbFugGr1IfUcVj8JBBNeRqR586HSx90LQvbHWbktfoY0IUmya4u2x1uekENOhY9BF2Nh Wnaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=uq4N62VcObOpr6hm1+yt24jW5Lh4EG5i+bJ9+JSrzn8=; b=kF/VLQRq9WoV6MvdtSt8CUVCOqdShPNCucTdHwv4Gb3pPXODG2ta5RR80av8r8SxoC K3RGQ1/y+9jvuRIJceu7etSVXGjve3pOTlNwFVZZb4FQDGtgG2SoINPJeijoZr19D0cH josI/Q5lmLXofdXHKvu/OS5/iSJ0qm25GDhRDsXzXuqeSPI713Eh3Vr3Ljj6lsS/YOoX c3wFmsxG6aPtl/cAMEWbtjdME1XdNx5JPSg6G8AMzwNFY7HgSX4Wf3V/s48M96zu+936 2XOCHPnywc08kCr0mWVjEXTsddLDKSd3R60T/dujohJLjLHQd2ESzBHwpjfLsgni392C E5aQ== X-Gm-Message-State: AN3rC/4Kb8XnlEOsIQBgWsd2MksGeA7JVgXmO4cm5n5leLrPT+x0Mw3nWpL6bJ2PUTkpQrXFf1doXJ3m6Xqqmg== X-Received: by 10.107.198.137 with SMTP id w131mr2892855iof.19.1491756636689; Sun, 09 Apr 2017 09:50:36 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Sun, 9 Apr 2017 09:50:36 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::b517] In-Reply-To: <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170408111144.GC14604@brick> <181f7b78-64c3-53a6-a143-721ef0cb5186@metricspace.net> <20170408115222.GA64207@brick> <7611f7a3-3e50-65f2-4347-e37018ae1abc@metricspace.net> <20170409155240.GA18363@brick> <8a60d967-eb7f-b529-df03-c0bfccbe9747@metricspace.net> From: Warner Losh Date: Sun, 9 Apr 2017 10:50:36 -0600 X-Google-Sender-Auth: zkX6U72fUJc7oD084joHMA5XRig Message-ID: Subject: Re: Proposal for a design for signed kernel/modules/etc To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 09 Apr 2017 19:46:29 +0000 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: Sun, 09 Apr 2017 16:50:38 -0000 On Sun, Apr 9, 2017 at 10:01 AM, Eric McCorkle wrote= : > On 04/09/2017 11:52, Edward Tomasz Napiera=C5=82a wrote: >> On 0409T1040, Eric McCorkle wrote: >>> On 04/08/2017 07:52, Edward Tomasz Napiera=C5=82a wrote: >>>> On 0408T0803, Eric McCorkle wrote: >>>>> On 04/08/2017 07:11, Edward Tomasz Napiera=C5=82a wrote: >>>>>> On 0327T1354, Eric McCorkle wrote: >>>>>>> Hello everyone, >>>>>>> >>>>>>> The following is a design proposal for signed kernel and kernel mod= ule >>>>>>> loading, both at boot- and runtime (with the possibility open for s= igned >>>>>>> executables and libraries if someone wanted to go that route). I'm >>>>>>> interested in feedback on the idea before I start actually writing = code >>>>>>> for it. >>>>>> >>>>>> I see two potential problems with this. >>>>>> >>>>>> First, our current loader(8) depends heavily on Forth code. By maki= ng >>>>>> it load modified 4th files, you can do absolutely anything you want; >>>>>> AFAIK they have unrestricted access to hardware. So you should pref= erably >>>>>> be able to sign them as well. You _might_ (not sure on this one) al= so >>>>>> want to be able to restrict access to some of the loader configurati= on >>>>>> variables. >>>>> >>>>> Loader is handled by the UEFI secure boot framework, though the conce= rns >>>>> about the 4th code are still valid. In a secure system, you'd want t= o >>>>> do something about that, but the concerns are different enough (and i= t's >>>>> isolated enough) that it could be done separately. >>>> >>>> Unless the way to address those ends up being a signature mechanism >>>> that doesn't depend on the format of the files being signed. >>> >>> I explored the idea of wrapped or detached signatures in the previous >>> discussion. Envelopes or detached signatures could make sense for the >>> 4th files. It's a small, obscure set of code that probably isn't >>> changed very often. >>> >>> Envelopes or detached signatures for kernel modules and especially >>> signed executables and libraries both have extensive, far-reaching >>> consequences for system administration, packaging, tooling, the ports >>> collection, and so on, whereas signing the executable with an additiona= l >>> section has no such consequences. >>> >>> Config files (and the 4th files really are more like config files) have >>> a different set of constraints, and detached signatures are probably th= e >>> way to go there. So loader should probably support detached PKCS#7 >>> signature checks. >> >> The third way that might be worth considering would be to just append >> the signature. This would work for both 4th (if you prepend it with >> whatever is the 4th comment character) and ELF, without the need for >> changing or extending either format. > > No, that won't work at all. That's going to break the tooling for ELF > files as well as applications that use them, and it won't work for any > configuration file aside from loader.4th It wouldn't even work for > boot.conf, for example. > > More generally, that's basing an entire standard off a dead language > that's used in only one place, and in a way the precludes compatibility > with any file format that uses a different comment character. It also > mandates some kind of ASCII encoding scheme to avoid newlines. You don't need to avoid new lines with 4th. It doesn't even need to be an ASCII encoding scheme, unless you are doing something crazy like trying to push the signature through the 4th parser, which is nuts. Forth can read binary files just fine. But I think arguing over the 4th stuff is a distraction, dee below. > If I was going to adopt a solution that broke existing tooling, I'd at > least go with a proper envelope scheme. That would be preferable. But why the either-or dichotomy? Seems like you're looking at the problem wrong if you are arguing about 4th code. You should be thinking more in terms of, at most, a couple of 4th words that can implement this stuff (so the loader could show that the kernel is signed and valid vs is not signed vs is signed, but the signature is bogus). 99% of the functionality should be in C, and should be sharable between the loader, the kernel and whatever else may wish to verify signatures before loading. It would also allow the same functionality to be pushed into the on-again-off-again LUA boot project (which seems to have momentum this time). Warner From owner-freebsd-security@freebsd.org Mon Apr 10 10:51:18 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 0D735D35749 for ; Mon, 10 Apr 2017 10:51:18 +0000 (UTC) (envelope-from johannes@perceivon.net) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 746A4FD4 for ; Mon, 10 Apr 2017 10:51:17 +0000 (UTC) (envelope-from johannes@perceivon.net) Received: by mail-lf0-x236.google.com with SMTP id h125so68356826lfe.0 for ; Mon, 10 Apr 2017 03:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perceivon-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:organization:message-id:date:user-agent :mime-version; bh=vwDiO8rb4PZaRErD7eArBbfylrUhB6YgKYcx5vf3MXA=; b=tyBfxQeryPpA1AIh/l3B4OuC60c5b1jLiQWuiN44a33luj/yjrcfIxvO9Ru5QgPEFV hDDQjuHECEPdOTZgTaH9XxDCf8JlBhRfUeW/dZW3z9emRMXvtEuUnE9CBuA51LJvsd3r AQOPRw6YH8dyfoAZ1fAv4gnphe567LVM9GoDt+xUeQ0B/GGrLXj/P+5xJ1WTlwxvm2l/ 5cqbmw20HzPxbsT9YBb0Kp8GDR9HL0T+842ls+JFrDAWlLoegDmqK0mk3v9XSlwMT3lV DI1v/CHMZ/KDVszeFygdGSgTQVyksR+08aXP1Ab3R5xv9Rcfowf2u/NxF2X8rvqJLZhK eMXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version; bh=vwDiO8rb4PZaRErD7eArBbfylrUhB6YgKYcx5vf3MXA=; b=O+3XhoFEeGgbnZbNR1GiGvf6eApnKabzIiRp9ApnpVTJuezWIsLq+dfo4NB++oXGb4 MDeCLIdhhW7eGQiPHjJTtm2402FDCE7QuhqZKNerjdZkt3yOYo3zjqrT79BfVruG/ftH CXtnYkpYhwIurk/qNWX+E7g3WqXdTjM9Jf26hvLcH6k0tlHB099nziAO1fBU9jFwMD1i uEMsmpZJs8+tLGANxKosSHiC2gzfsJSaqxiM3lluLqOvku1JXerndILQsdGGGbg2i5Kg o5qa6sJHVtmvIgdBub/2qb2nXkA294OQDfZZWmxtFAiy5EICbACqufC0QecMdgKCM8mo EPSA== X-Gm-Message-State: AFeK/H1P5Yk2wkGBAY5fzaDVnFBpqceZRUirCQqHhdYWU4gsa7lPzbTJowDu81JUoOOLqv1XIRQizK9X9/a3j53GoWH8g5lAkWlD7UeVcLXJAKkRiqiOB7N3yoYg+Vx+z3jV8hS1BoSzkOXkV6MC4Z8pimHGnAMcjeUmg+tlY5XtzfRYSEZrewpFBC4hT0Z/zgUW X-Received: by 10.46.76.2 with SMTP id z2mr14654421lja.38.1491821474927; Mon, 10 Apr 2017 03:51:14 -0700 (PDT) Received: from mx16 (101.177.50.84.sta.estpak.ee. [84.50.177.101]) by smtp.gmail.com with ESMTPSA id 9sm2735418ljg.37.2017.04.10.03.51.14 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Apr 2017 03:51:14 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mx16 (OpenSMTPD) with ESMTP id 2bbc4596 for ; Mon, 10 Apr 2017 13:50:43 +0300 (EEST) To: freebsd-security@FreeBSD.org From: Johannes Jost Meixner Subject: ntp vulnerabilities disclosed 2017-03-21 Organization: Perceivon Hosting Inc. Message-ID: Date: Mon, 10 Apr 2017 13:50:40 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="okNCdA0qOcBecnK1UmAuKmR3CTht5bgDW" X-Mailman-Approved-At: Mon, 10 Apr 2017 11:24:05 +0000 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, 10 Apr 2017 10:51:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --okNCdA0qOcBecnK1UmAuKmR3CTht5bgDW Content-Type: multipart/mixed; boundary="xLxjku1BqEK7FAhlSoW16t1i7FAmNqLh6"; protected-headers="v1" From: Johannes Jost Meixner To: freebsd-security@FreeBSD.org Message-ID: Subject: ntp vulnerabilities disclosed 2017-03-21 --xLxjku1BqEK7FAhlSoW16t1i7FAmNqLh6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable NTP publicly disclosed a list of vulnerabilities, and corresponding fixes, on March 21[1]. The patched ntp 4.2.8p10 has been imported to 12.0-CURRENT on March 23[2], but a merge from current to releng/11.0 and releng/10.3 branches seems to still be missing. Is someone working on fixing that, and if so, how long until the SA is made public? Thanks -Johannes --xLxjku1BqEK7FAhlSoW16t1i7FAmNqLh6-- --okNCdA0qOcBecnK1UmAuKmR3CTht5bgDW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEwY8kko8dNupPoLLvSWqdcGJQ1AIFAljrY4MACgkQSWqdcGJQ 1AKtlw//SCoh49wDr7c4bt/BR7hptuWbX0HqQo0g3C8Fpyk3gGkHwRKUHnD1ElIX f3ml6M4Dq8chG5UhHUlLLq7Hq6Bs9ZDnKUCYUBsjj8TuKC6Zda/DJm0sJj1IaUL0 oUmX7/Eo7Bz3o/Sy7vpK/w4/62JwDI9cI/Pe0FclQ3Jv24US18e0n8kFdDk5E3xe OdFbPEoN6RgpYqyrmfkm3DFKycmgCH94F/fjJ2W7t7mQt0daDJo78yuhdJ/Aw/QA eD/7baYZ5EtgFzRHss352W2DP/w9IhAiZ8yEoGqDAegwUoo+9YwM+Mtk4h7JZrUg i+zZkAlz3ydlx8GizqaPwPvG4gjCSiIKzvNUxEREmcQAbIZqZ6YGAYtmG0syj5pQ X3jB8fUSQpATfhiDbXEqjetmgCtciiA7ZJFUWtGGgRMO6aDm18sKvZqT1fxI/oBs u7ilbAGT9M6L9JK0dV9IynfZCpZGu7zQniLNAQI6n0nBTUsrgyPmxuyC1t+pgeMl QZkwMRsv1cn3XRHMc7/3JlZGX3rM+FJJ4I3cmYxpKIgYkR2NRueOALuByjv3I19+ Yy+3TO/TMFoVW1+0NEJkWRE+PtcXDqcN9j78xRyIqopuQAM7f+g5vfZUvHpW/xnt vQHm7UkW81Y8Qxwzgqm27BOjdUgE9Uk2uH61M4D8Bs1KfkxZIhQ= =kV8T -----END PGP SIGNATURE----- --okNCdA0qOcBecnK1UmAuKmR3CTht5bgDW-- From owner-freebsd-security@freebsd.org Wed Apr 12 07:23:59 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 17B2FD3A5A1 for ; Wed, 12 Apr 2017 07:23:59 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 F102CE16; Wed, 12 Apr 2017 07:23:58 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1035) id 2DDF4924; Wed, 12 Apr 2017 07:23:58 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-17:03.ntp Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20170412072358.2DDF4924@freefall.freebsd.org> Date: Wed, 12 Apr 2017 07:23:58 +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: Wed, 12 Apr 2017 07:23:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-17:03.ntp Security Advisory The FreeBSD Project Topic: Multiple vulnerabilities of ntp Category: contrib Module: ntp Announced: 2017-04-12 Credits: Network Time Foundation Affects: All supported versions of FreeBSD. Corrected: 2017-03-28 04:48:17 UTC (stable/11, 11.0-STABLE) 2017-04-12 06:24:35 UTC (releng/11.0, 11.0-RELEASE-p9) 2017-03-28 04:48:55 UTC (stable/10, 10.3-STABLE) 2017-04-12 06:24:35 UTC (releng/10.3, 10.3-RELEASE-p18) CVE Name: CVE-2017-6464, CVE-2017-6462, CVE-2017-6463, CVE-2016-9042 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP) used to synchronize the time of a computer system to a reference time source. II. Problem Description A vulnerability was discovered in the NTP server's parsing of configuration directives. [CVE-2017-6464] A vulnerability was found in NTP, in the parsing of packets from the DPTS Clock. [CVE-2017-6462] A vulnerability was discovered in the NTP server's parsing of configuration directives. [CVE-2017-6463] A vulnerability was found in NTP, affecting the origin timestamp check function. [CVE-2016-9042] III. Impact A remote, authenticated attacker could cause ntpd to crash by sending a crafted message. [CVE-2017-6463, CVE-2017-6464] A malicious device could send crafted messages, causing ntpd to crash. [CVE-2017-6462] An attacker able to spoof messages from all of the configured peers could send crafted packets to ntpd, causing later replies from those peers to be discarded, resulting in denial of service. [CVE-2016-9042] IV. Workaround No workaround is available, but systems not running ntpd(8) are not affected. Network administrators are advised to implement BCP-38, which helps to reduce the risk associated with these attacks. 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. The ntpd service has to be restarted after the update. A reboot is recommended but not required. 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 The ntpd service has to be restarted after the update. A reboot is recommended but not required. 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] # fetch https://security.FreeBSD.org/patches/SA-17:03/ntp-11.0.patch.xz # fetch https://security.FreeBSD.org/patches/SA-17:03/ntp-11.0.patch.xz.asc # gpg --verify ntp-11.0.patch.xz.asc [FreeBSD 10.3] # fetch https://security.FreeBSD.org/patches/SA-17:03/ntp-10.3.patch.xz # fetch https://security.FreeBSD.org/patches/SA-17:03/ntp-10.3.patch.xz.asc # gpg --verify ntp-10.3.patch.xz.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/10/ r316069 releng/10.3/ r316722 stable/11/ r316068 releng/11.0/ r316722 - ------------------------------------------------------------------------- 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----- Version: GnuPG v2.1.19 (FreeBSD) iQIzBAEBCgAdFiEEHPf/b631yp++G4yy7Wfs1l3PaucFAljty+gACgkQ7Wfs1l3P audFpxAA30Po/44RV8x98fcopL+/qX0bKhs2yORCcYs/ebrPaDW6ghdqPAPyNDen qJSoEU6FFZxU508reu6mcJIze0YzSC2D4Xe+BjtVjTUhgZ1mUlfx+0Dqa6DsmyPE wreYZ0+aPJPSg82P4pOR+Oo4Omh0BHXw/Yu+uJxd+VSGAWg9zJk9QcRyy3QKsPFn YbMYjAsMk1x2i/q6GzRnoJXAFT9c1QsKRP1QU3JivDEQEYwreqKxkG7Ex9OkUOmL CIPVG19K7iddnMfiQPjhPhyAOFWrtKMm1rjcg1vSEMUQ24MtVotGOgNkKXEf0vjT eVX91sIRYGgy9utg6Mg4pnDT7m94PMh7mORgfphHg7l7LFVGYKAbHF7khIMtrs4k /ZU5i7xZqKR6xNm4oWtaBC9EipkWfjnXjBRG30t3kdD2r7ElJ+Y3mvPdalFsxd+U gP2Wgn//byToXVUGFLChR7KSWDOjUpdiGu3UUDG4LmG/U4whDsSobPgOF3SzbALF mx8f7OWkOYCnQ9WuhI3PVvCdLncjZ5UdLaQ5nP53pn3rGk9C4MJpGlTI2iS1gwFV n09mE5zXueI3jVJm+An2X2Z3C8fTCRHb7n3Sej2wnrgiXk8z/8ftX6VJcUxdgW+A OYFztl0iKgjgEXix33FZ5baivohQVhAT5rUQRQ/+gcrvL8rbJQg= =58Te -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Wed Apr 12 08:37: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 91279D38220 for ; Wed, 12 Apr 2017 08:37:06 +0000 (UTC) (envelope-from yz@yz.kiev.ua) Received: from nb.yz.kiev.ua (nb.yz.kiev.ua [92.63.99.5]) (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 343A6688 for ; Wed, 12 Apr 2017 08:37:06 +0000 (UTC) (envelope-from yz@yz.kiev.ua) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=yz.kiev.ua; s=dkim; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=xX7me3w3mt56xrUNoi1cTIjzBiDzry5/UCLSFVBjw84=; b=e5OWGVUgisdPV+dJLqPUEt7c1/ qRyXBwXQ+mMPkBTbGFl9Gb7JGOIHUPNBuN1HDj6G6WqbE3odycnvHVPC5hBC2aWtZj0RiIcUJFuKt qjTBYcAY4X8lPJf8ELqvm4M/P7r2PgeMzfZ2z4Gm/uCKKk96wCcWhVJY5ksf9hCct14Q=; Received: from yz by nb.yz.kiev.ua with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1cyDV8-0004LN-06 for freebsd-security@freebsd.org; Wed, 12 Apr 2017 11:19:42 +0300 Date: Wed, 12 Apr 2017 11:19:41 +0300 From: "George L. Yermulnik" To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-17:03.ntp Message-ID: <20170412081941.GC13565@yz.kiev.ua> References: <20170412072358.32CB8926@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170412072358.32CB8926@freefall.freebsd.org> Organization: Earth, Europe, Ukraine, Kiev X-Yz-Mark: yz@nb 20170412 11:18:45 User-Agent: Mutt/1.8.0 (2017-02-23) X-Mailman-Approved-At: Wed, 12 Apr 2017 10:56:44 +0000 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, 12 Apr 2017 08:37:06 -0000 Hello! On Wed, 12 Apr 2017 at 07:23:58 (+0000), FreeBSD Security Advisories wrote: [...] > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > [FreeBSD 11.0] > # fetch https://security.FreeBSD.org/patches/SA-17:03/ntp-11.0.patch.xz > # fetch https://security.FreeBSD.org/patches/SA-17:03/ntp-11.0.patch.xz.asc > # gpg --verify ntp-11.0.patch.xz.asc > [FreeBSD 10.3] > # fetch https://security.FreeBSD.org/patches/SA-17:03/ntp-10.3.patch.xz > # fetch https://security.FreeBSD.org/patches/SA-17:03/ntp-10.3.patch.xz.asc > # gpg --verify ntp-10.3.patch.xz.asc > b) Apply the patch. Execute the following commands as root: > # cd /usr/src > # patch < /path/to/patch Looks like `unxz ...' command is missing here. [...] -- George L. Yermulnik [YZ-RIPE]