From owner-freebsd-security@freebsd.org Mon Apr 20 14:00:21 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 78BDF2C3DD5 for ; Mon, 20 Apr 2020 14:00:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 495SyD3wygz4Pj9 for ; Mon, 20 Apr 2020 14:00:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f176.google.com with SMTP id q10so8474436ile.0 for ; Mon, 20 Apr 2020 07:00:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dZf34HU0tWjyWmfI3wCOkX1jlsKOIhX+Itc8gnFbEo8=; b=l6XM4Vo+skHg30muj6Cd5VFw3vp8Rs3IbcFqtB6zTMCYGU9+tQPRyocVoH2o1SCF3t 2cU/sedFpCzkPruGylc9CM9PSsinpyEaIqZ1ck5x+F70JzMyFPQqjGR9np8RmWCh6t90 zhoig86SSDPYoM2fBqz+EtTFzVzjnHs1ugvycfb4Ue084N75aAFGkXRcbHv6zzwD8ooz E6LkdlyPeiK50t6mkoNzUpmX1vsyS2DQMkdQg+GBUu1hmBR/XUCxSsjfvkMdEy+xphvI hKr26NNOM43yMXqzxSeycBBiajVWldWjKqesg+UMd5ERDP49x5lPsMBYQv+JuRNWHnnB zabA== X-Gm-Message-State: AGi0PuYGE5L4Dv8KaZflHDaUE/HZO/UVbYdpRMUvqs7+45OAUxe2vtPp ORS0cN1VR73POQsDAQjT4GIVzaBNVDnf0O9DZgddEQ== X-Google-Smtp-Source: APiQypJ2u4HH8ojDxzndVvFHb/9c0X9dnxVJ7n9xXxl/Yh5KBTCfNp0hN4l3+4mlXjQI5BzFCmg4J46aq9NaIbA9Zoc= X-Received: by 2002:a92:41c7:: with SMTP id o190mr15578418ila.11.1587391218926; Mon, 20 Apr 2020 07:00:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Mon, 20 Apr 2020 10:00:06 -0400 Message-ID: Subject: Re: ASLR/PIE status in FreeBSD HEAD To: Dewayne Geraghty Cc: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 495SyD3wygz4Pj9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.176 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.22 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[176.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.22)[ip: (-5.21), ipnet: 209.85.128.0/17(-0.40), asn: 15169(-0.43), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[176.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 14:00:21 -0000 On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty wrote: > > I'm on a similar ride. We run applications in both i386 and amd64 jails > with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good. Great! > On the build server, the i386 jail with aslr enabled wasn't able to > build gcc9; so this was disabled kern.elf32.*. i386 has little spare address space and compiling applications as PIE has a significant performance impact there, so enabling it only on 64-bit seems quite reasonable. > ntp was the only real application that didn't play nicely with aslr. > Fortunately, this was very helpful: > > /usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpd... Yes, and you can now (if using stable/12 or -CURRENT) use elfctl to tag the binary with a note to request randomization be disabled for the process, although we really should address the underlying issue. From owner-freebsd-security@freebsd.org Mon Apr 20 14:22:14 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7D73B2C48F5 for ; Mon, 20 Apr 2020 14:22:14 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 495TRT4p7Qz4S5R for ; Mon, 20 Apr 2020 14:22:13 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-qt1-x835.google.com with SMTP id w29so8550376qtv.3 for ; Mon, 20 Apr 2020 07:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+HyevYGSPR0FvFN4x/fF1TtPZNhzTEf8r4v8SWmrp5E=; b=tynewFQQ5vsa451mwJzsjHdaAFM5+tkoUA83CtzbhqVa/4dLk+MvkXB6WjHsmEdpHc HIF7PDrtLfrryarEC9CsXTQk9c6NjYwReZF9BjJNGTgaWQLm+Fvc0OsBpeQZybAhMQHp FNhhqr/KPz/894CrcBqS0RIRrRwMuVrlPt7aKJJYToiicCH69TNquoqggoEyv2qNtJkG sv9CaxpC0MZguRWdPrX7KSSg+wWxne+JaWNRhIQcI+9WAeBtJyLd7/F95K4saM3Am4Pd CNhlW8VgBZl5nsFaCscQODjvVuyXrZDaP7EieSO7FuxPf3PAdHHQaNy1/HCMuLHgOMS0 um2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+HyevYGSPR0FvFN4x/fF1TtPZNhzTEf8r4v8SWmrp5E=; b=XoSek6O4a1QM6faYTYUs6HJyXiKjdMV9FFwO5u8vR7mTEPqWdPjLnNYCRNVfKjfEyJ bdPzE1gmkL8p9aDnhnrEuUn3UZ/p5AgitcMOa/Uq4brwS74Pyuc0qZjQhOPmvd8TBbXZ tm1iATazC+O7r0Rwt3rY+ij6VwIWxrxumIEPHagivFo7ApSWNYvAtPuJBAedTBMp9xqI hdB+49DVQfg8ltR8F5ZxJ7exFm3xcLpKrjS5P1u0WP6lVjErdV1A3cOeJc0h6QZsZNqm g+70kUvxy4fnR034Jm1eSoj3bKS0aIgtbfVG/VsLiYtDv79F9/kri8GlPxVPgELBJOhG Ib9g== X-Gm-Message-State: AGi0Pua08xVWOc8U5ffUcauwpdnxrxAGMtX5YT54BfNtzw3s7VMsV+OS V/M0GINcOBaiHfhMgkYkw3KaLMcXDDjyY6BZncrAbGozLds= X-Google-Smtp-Source: APiQypKjM2ftpASQoPvFjowyBWSA1L5ylOMOmvxl3JY4SzjOmMB2wEBqu0LWgaZ2wlUYu94DGYcS3z0Vb+oolP4WR+s= X-Received: by 2002:aed:3ec2:: with SMTP id o2mr16057862qtf.30.1587392532314; Mon, 20 Apr 2020 07:22:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Mon, 20 Apr 2020 16:21:59 +0200 Message-ID: Subject: Re: ASLR/PIE status in FreeBSD HEAD To: Ed Maste Cc: freebsd-security@freebsd.org, Rafal Jaworowski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 495TRT4p7Qz4S5R X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=tynewFQQ; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2607:f8b0:4864:20::835) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-4.31 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[semihalf-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[5.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.01)[ip: (-9.27), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 14:22:14 -0000 Hi Ed, pt., 17 kwi 2020 o 15:52 Ed Maste napisa=C5=82(a): > > On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > > > Hi, > > > > Together with our customers, Semihalf is interested in improving the st= atus > > of security mitigations enablement in FreeBSD. > > Happy to hear that there's interest in this work! > > > 1. Are there any hard blockers, like missing features or bugs, that pre= vent > > enabling ASLR by default in the kernel and building the base system wit= h > > -DWITH_PIE? > > I believe there are no showstopper issues but there are a some > prerequisites. One is that there are some applications that may > misbehave with randomization enabled. They would need to be > identified, and tagged (with the elfctl tool now in the base system). I was thinking if it is possible to come up with such wide test coverage to test every single application from the base system. Do you think it is achievable or should we rather follow the approach to do as many tests as possible, but rely on the community feedback to catch the corner cases (like the ntpd issue mentioned in this thread)? What about the ports? > > > 2. In case the enablement becomes eventually approved, will it be bette= r to > > do it for all archs or focus only on the selected ones? > > There's a general and increasing preference of avoiding different > defaults per architecture. One issue though is that some options may > have much larger performance impacts on certain architectures - e.g. > position independent executables (PIE) on i386. Understood. If there is likely a performance trade-off, how about doing tests e.g. on i386 and armv7? In case of a big drop or other issues, could limiting ALSR/PIE to 64-bit-only be a considered solution? > > > 3. IMO it may be worth to benchmark/stress the system for the stability > > verification and perf comparison purpose. Do you think it may be reason= able > > to create a kind of reference matrix (archs vs tests)? Those could be d= one > > to evaluate the current state of the OS, but also for validating each > > proposed feature. I also think engaging the FreeBSD CI might be a huge = help > > in such an effort. BTW, any particular tests / benchmarks come to your = mind > > as useful in this case? > > Yes, benchmarking and testing are very important tasks on a path to > enabling these by default. I agree with the CI comment; we should > start with CI build + kyua runs with options turned on, in advance of > changing the default. Indeed I thought of kyua and measuring buildworld execution time for stressing the DUT and having the first comparison numbers for the low price. Do you think it is possible to get help here, i.e. is there a FreeBSD devops team, maintaining the Jenkins CI whose spare cycles could be used for this purpose? Or is this a field requiring external help from interested parties? Even before the automation, would it be useful to perform some runs on chosen archs? > > I would be interested in seeing macro-level benchmarking with > mitigations on/off - for example, I assume Firefox must have a > performance test suite that they use for tracking their own > performance changes during development, and we could use benchmarks > like that to see the impact of mitigations. Coming up with a full set > of appropriate benchmarks will be a useful endeavour. Yes, making use of something actively maintained would be great. Do you see a need for IO stressing/benchmarking for the discussed cases? Best regards, Marcin From owner-freebsd-security@freebsd.org Mon Apr 20 14:42:08 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C64442C50EF for ; Mon, 20 Apr 2020 14:42:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 495TtS2stVz4TlV; Mon, 20 Apr 2020 14:42:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 03KEfx3o030057 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Apr 2020 17:42:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 03KEfx3o030057 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 03KEfxK7030056; Mon, 20 Apr 2020 17:41:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 20 Apr 2020 17:41:59 +0300 From: Konstantin Belousov To: Ed Maste Cc: Dewayne Geraghty , freebsd-security@freebsd.org Subject: Re: ASLR/PIE status in FreeBSD HEAD Message-ID: <20200420144159.GT2655@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 495TtS2stVz4TlV X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 14:42:08 -0000 On Mon, Apr 20, 2020 at 10:00:06AM -0400, Ed Maste wrote: > On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty > wrote: > > > > I'm on a similar ride. We run applications in both i386 and amd64 jails > > with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good. > > Great! > > > On the build server, the i386 jail with aslr enabled wasn't able to > > build gcc9; so this was disabled kern.elf32.*. > > i386 has little spare address space and compiling applications as PIE > has a significant performance impact there, so enabling it only on > 64-bit seems quite reasonable. With 4/4 i386 gained +1G for UVA, which makes i386 binaries behaviour on i386 kernel almost identical to amd64 kernel. > > > ntp was the only real application that didn't play nicely with aslr. > > Fortunately, this was very helpful: > > > > /usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpd... It is really -m stackgap that hurted ntpd, but I remember that the code which was causing problems, was removed since then. > > Yes, and you can now (if using stable/12 or -CURRENT) use elfctl to > tag the binary with a note to request randomization be disabled for > the process, although we really should address the underlying issue. From owner-freebsd-security@freebsd.org Tue Apr 21 16:55:15 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 252242ABB07 for ; Tue, 21 Apr 2020 16:55:15 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4968nZ71L3z4ZMP; Tue, 21 Apr 2020 16:55:14 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 945) id CA8D71CCBD; Tue, 21 Apr 2020 16:55:14 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-20:10.ipfw Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20200421165514.CA8D71CCBD@freefall.freebsd.org> Date: Tue, 21 Apr 2020 16:55:14 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 16:55:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-20:10.ipfw Security Advisory The FreeBSD Project Topic: ipfw invalid mbuf handling Category: core Module: kernel Announced: 2020-04-21 Credits: Maxime Villard All supported versions of FreeBSD. Corrected: 2019-12-23 10:02:55 UTC (stable/12, 12.1-STABLE) 2020-04-21 15:52:22 UTC (releng/12.1, 12.1-RELEASE-p4) 2019-12-23 10:06:32 UTC (stable/11, 11.3-STABLE) 2020-04-21 15:52:22 UTC (releng/11.3, 11.3-RELEASE-p8) CVE Name: CVE-2019-5614, CVE-2019-15874 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ipfw system facility allows filtering, redirecting, and other operations on IP packets travelling through network interfaces. II. Problem Description Incomplete packet data validation may result in accessing out-of-bounds memory (CVE-2019-5614) or may access memory after it has been freed (CVE-2019-15874). III. Impact Access to out of bounds or freed mbuf data can lead to a kernel panic or other unpredictable results. IV. Workaround No workaround is available. Systems not using the ipfw firewall are not vulnerable. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot. Perform one of the following: 1) 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 # shutdown -r +10min "Rebooting for a security update" 2) 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.3] # fetch https://security.FreeBSD.org/patches/SA-20:10/ipfw.11.patch # fetch https://security.FreeBSD.org/patches/SA-20:10/ipfw.11.patch.asc # gpg --verify ipfw.11.patch.asc [FreeBSD 12.1] # fetch https://security.FreeBSD.org/patches/SA-20:10/ipfw.12.patch # fetch https://security.FreeBSD.org/patches/SA-20:10/ipfw.12.patch.asc # gpg --verify ipfw.12.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/12/ r356035 releng/12.1/ r360149 stable/11/ r356036 releng/11.3/ r360149 - ------------------------------------------------------------------------- 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----- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl6fHK1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cJnFA//Zqygqhfo2vs/FBe67+/MILbAn5KeZoha6jbhr7YGD//Yzdy0+LtiaMpL DskM6z2bF6VKMuB5XQufUcAPTqzf8m3pgdFoPBT2P47ndkqDsF7/EDe5IaYCQZq+ CB0tTuD6m3/8qYXvKyD+c6WV92Tn75GOpguKEYWnoBlOe8YVoVWxIknl+wuG+w4h D6hGGntvvs7RyXVITo9wzW70W8b57fIszVHTvH0YoFwBLGeie/uNomkcawti6jcp h703a4VsGeM1FFqb8hrNgKdDMC8Xmddjd78PMxl4wjC4WrrziQ1M8RxEoLHCSrH0 4hLSjQOIVuI+OoEArn533QyHWQa1KbeECc2GgSlUrq6rlNk3SELWl72tugETT0JJ EYWFaLUGLUV5PMeuv7c6HfuXXtaVOEP/Gyvf9Rduesohdzw+DYrzXSyVv9wsRbfx 34H9Xcjlu+BzYrHyKJkgdILwEFpEHCZmxRLxeJLGBjPAsudhN2XzGfKEQNd8olTr pe0Cw+C/sBhe0jh42REDRXW/Vr0YF4ivZf6L8d1zdG462GMn9aZteCjRmfMOWN1D BjU0+qY6mkWU0bVep0sjPU9ON8T9vnEinjhfqIb/A9XOvKag7cehpxWC+PJyf3I4 eAjdzQeq0FH08XMWFfFWDqa7VmGYhmp/e53HNbHb90NtW07GtHE= =p+5n -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Tue Apr 21 16:55:20 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A9D3D2ABB7A for ; Tue, 21 Apr 2020 16:55:20 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4968nh3C3Bz4ZQ5; Tue, 21 Apr 2020 16:55:20 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 945) id 51D141CE03; Tue, 21 Apr 2020 16:55:20 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-20:11.openssl Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20200421165520.51D141CE03@freefall.freebsd.org> Date: Tue, 21 Apr 2020 16:55:20 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 16:55:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-20:11.openssl Security Advisory The FreeBSD Project Topic: OpenSSL remote denial of service vulnerability Category: contrib Module: openssl Announced: 2020-04-21 Credits: Bernd Edlinger Affects: FreeBSD 12.1 Corrected: 2020-04-21 15:47:58 UTC (stable/12, 12.1-STABLE) 2020-04-21 15:53:08 UTC (releng/12.1, 12.1-RELEASE-p4) CVE Name: CVE-2020-1967 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It is also a full-strength general purpose cryptography library. II. Problem Description Server or client applications that call the SSL_check_chain() function during or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the "signature_algorithms_cert" TLS extension. The crash occurs if an invalid or unrecognized signature algorithm is received from the peer. III. Impact A malicious peer could exploit the NULL pointer dereference crash, causing a denial of service attack. IV. Workaround No workaround is available. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Perform one of the following: 1) 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 # shutdown -r +10min "Rebooting for a security update" 2) 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. # fetch https://security.FreeBSD.org/patches/SA-20:11/openssl.patch # fetch https://security.FreeBSD.org/patches/SA-20:11/openssl.patch.asc # gpg --verify openssl.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 all daemons that use the library, or reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/12/ r360147 releng/12.1/ r360150 - ------------------------------------------------------------------------- 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----- iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl6fHLBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n 5cJEGw/7BWgBW3Vi98Sj0OFQnKUyckFaKxOY5WNl+N2k1MC5QIwtFRknS/i4xiBe wfpudj8PRiYe5sXC7C0vpHBB6LAq9RCflZAu3auRD/r/wShAq1wVY6nC7zJ+nXKX r7OuUj0NBQK7Gc5k89LEeRI8qjcJv7XwUY63msVvDUzqWwZeVDufrRnSwoUi0LR/ qbya9ICb9qt7o52QNpECccEUVB4Qc1mfdESpDi/7h/JYXvLptsa/W6DtTZRlJ2n/ f/hi2ja7xUD78NlQ6Sbc17+QUFWWIvyljl255Nhi3YhjWpFSWewmJg3aLqQ3O4uB g632jncGVFtRiDWHvUPqIx0Ephs3Ubd0llBsWXJ4uEQzeqVVVk05oomWDBjUoxW/ Iw7kfVJDBNrrIuNikhOaf3lmUEJ8iXUhg8NxLwoyq6v2SM2eFLqYxx9MLwH5RQkV nAuWszYSnxkReUE4oGrm7Vn3Mq7yhiM8KpNS08BSADeWRWEJSsdeA5BC2bLIUgE+ UKRDYaTyLSl9knHNmCd9W/8b3w03k2E4lrosc+hiaYoVB9l83e5elQm/tgdBynmL w653iJIoATgApXXresLW3x/by9+BhCq1fLkipDoaRZTrsg7zaYCyseDmfvmaV6Pn x8nm+i+VHeB8hp+vurijO9wuaisPs4LNv7pPcler2LmtAGYV3Lg= =231J -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Tue Apr 21 19:29:06 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B0B312B6989 for ; Tue, 21 Apr 2020 19:29:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 496DC63KQ2z3PKj for ; Tue, 21 Apr 2020 19:29:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03LJSo2G024422 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 21 Apr 2020 19:28:51 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Received: from [10.58.0.10] (dadv@dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03LJSiww070990 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 22 Apr 2020 02:28:44 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-20:10.ipfw To: freebsd-security@freebsd.org References: <20200421165514.C676C1CB78@freefall.freebsd.org> From: Eugene Grosbein Message-ID: <54bfc0f6-be4c-349d-df87-8ba507803a04@grosbein.net> Date: Wed, 22 Apr 2020 02:28:43 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20200421165514.C676C1CB78@freefall.freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 496DC63KQ2z3PKj X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 19:29:06 -0000 21.04.2020 23:55, FreeBSD Security Advisories wrote: > ============================================================================= > FreeBSD-SA-20:10.ipfw Security Advisory > The FreeBSD Project > > Topic: ipfw invalid mbuf handling [skip] > IV. Workaround > > No workaround is available. Systems not using the ipfw firewall are > not vulnerable. This is not true. The problem affects only seldom used rules matching TCP packets by list of TCP options (rules with "tcpoptions" keyword) and/or by TCP MSS size (rules with matching "tcpmss" keyword, don't mix with "tcp-setmss" action keyword). Systems not using "tcpoptions" nor "tcpmss" keywords to match TCP packets are not affected. For example, system using any of default templates (open/client/simple/closed/workstation) are not affected. Please consider re-checking this and adjusting the Advisory. From owner-freebsd-security@freebsd.org Tue Apr 21 22:15:44 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CDB202BC859 for ; Tue, 21 Apr 2020 22:15:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 496HvM2whPz4JSt; Tue, 21 Apr 2020 22:15:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f177.google.com with SMTP id s10so14194028iln.11; Tue, 21 Apr 2020 15:15:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=03oNog6XlhRcwYfJMPSbjY+IOgVjToTo2SQdB3JEuJE=; b=CN8zA1FRmJ6Od20RrveUJLQLTNPitDmz11JnFts8biBBtWpS5sreoXnnLzgBVDxiSg kHiLMJB37vbHTeIve4wc78GIxkgdt7YReoIqN+h1EsqwBmIDmDi73Mvj1D9Q1+L5N6XR bSJ3IuqNFd4fBnCrpL5+rTfLoahNmPRrqFNNP3KQmTC/Pfvqfyg5bUywzWJWRRkltvWa 2CXcBK3iumxW/KMNZp6ABjKtCY6cZ1K6IUBu3dTeIClgXrveJEvsDB5YHWNfP9xbYRNg Vo01CqBAQNCCvxWjWy0OaAlPJfCSIl0kBfXZNSxOSIMO3gvRKyZ5Jmfkg8HBlD9qVTY4 U3zQ== X-Gm-Message-State: AGi0PuYBzrTbDSwAqkKbpHKMeRo43ODqDp77j28r4Srob4/xpFBeWmEW iinsqhW01Vk+vSNoiDizY5XhLdpmodD6o5J/rFhsVAtu X-Google-Smtp-Source: APiQypIuixYjDIEpmVLXHV7oyb7FCidet3seJfg5LzFHxCrUokLdhlh7MKCX/7/Utxpw/RrX7Y4JSiy9ijc5kzSXuE4= X-Received: by 2002:a92:2910:: with SMTP id l16mr21116500ilg.256.1587507342281; Tue, 21 Apr 2020 15:15:42 -0700 (PDT) MIME-Version: 1.0 References: <20200421165514.C676C1CB78@freefall.freebsd.org> <54bfc0f6-be4c-349d-df87-8ba507803a04@grosbein.net> In-Reply-To: <54bfc0f6-be4c-349d-df87-8ba507803a04@grosbein.net> From: Ed Maste Date: Tue, 21 Apr 2020 18:15:29 -0400 Message-ID: Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-20:10.ipfw To: Eugene Grosbein , "Andrey V. Elsukov" Cc: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 496HvM2whPz4JSt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.177 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.55 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[177.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.55)[ip: (-6.87), ipnet: 209.85.128.0/17(-0.40), asn: 15169(-0.43), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[177.166.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 22:15:44 -0000 On Tue, 21 Apr 2020 at 15:29, Eugene Grosbein wrote: > > 21.04.2020 23:55, FreeBSD Security Advisories wrote: > > ============================================================================= > > FreeBSD-SA-20:10.ipfw Security Advisory > > The FreeBSD Project > > > > Topic: ipfw invalid mbuf handling > > [skip] > > > IV. Workaround > > > > No workaround is available. Systems not using the ipfw firewall are > > not vulnerable. > > This is not true. The problem affects only seldom used rules matching TCP packets > by list of TCP options (rules with "tcpoptions" keyword) and/or by TCP MSS size > (rules with matching "tcpmss" keyword, don't mix with "tcp-setmss" action keyword). I believe this is correct; what about this statement: No workaround is available. Systems not using the ipfw firewall, and systems that use the ipfw firewall but without any rules using "tcpoptions" or "tcpmss" keywords, are not affected. From owner-freebsd-security@freebsd.org Tue Apr 21 22:50:32 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 01FA02BD158 for ; Tue, 21 Apr 2020 22:50:32 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 496JgV1r67z4KmP; Tue, 21 Apr 2020 22:50:29 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03LMoJKr028841 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Apr 2020 22:50:22 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: emaste@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03LMoIoh073831 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2020 05:50:18 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-20:10.ipfw To: Ed Maste , "Andrey V. Elsukov" References: <20200421165514.C676C1CB78@freefall.freebsd.org> <54bfc0f6-be4c-349d-df87-8ba507803a04@grosbein.net> Cc: freebsd-security@freebsd.org From: Eugene Grosbein Message-ID: Date: Wed, 22 Apr 2020 05:50:12 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 496JgV1r67z4KmP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.89)[ip: (-5.23), ipnet: 2a01:4f8::/29(-2.64), asn: 24940(-1.54), country: DE(-0.02)]; R_SPF_PERMFAIL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 22:50:32 -0000 22.04.2020 5:15, Ed Maste wrote: >>> IV. Workaround >>> >>> No workaround is available. Systems not using the ipfw firewall are >>> not vulnerable. >> >> This is not true. The problem affects only seldom used rules matching TCP packets >> by list of TCP options (rules with "tcpoptions" keyword) and/or by TCP MSS size >> (rules with matching "tcpmss" keyword, don't mix with "tcp-setmss" action keyword). > > I believe this is correct; what about this statement: > > No workaround is available. Systems not using the ipfw firewall, and > systems that use the ipfw firewall but without any rules using "tcpoptions" > or "tcpmss" keywords, are not affected. Isn't removing rules with "tcpoptions/tcpmss" considered as work-around? Such rules may be replaced with "ipfw netgraph" rules and processing TCP options with NETGRAPH node ng_bpf(4). Seems as work-around to me. From owner-freebsd-security@freebsd.org Tue Apr 21 23:55:33 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 497DB2BE62D for ; Tue, 21 Apr 2020 23:55:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 496L6X3xkJz4PDp; Tue, 21 Apr 2020 23:55:32 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f48.google.com with SMTP id f3so511796ioj.1; Tue, 21 Apr 2020 16:55:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aRb9PwSM5QnsnlcPfatBEm41ignAVvPLYItT98IyCyo=; b=J8qZUBAPpbGxVA5hw0PcJq8QPhtK0zOQc/+09/uuQOXBAQ1xpE2+vKrdRIxfdlKBVh pNUiAOkyOratAIrMQKv4zJWkDqk92p4jjl1yGTOyaqbcg1LupYZEzg92PIvfMp1LYJfa RE/nyZBW1+aArG83pmtWg53YZVtDzkzCDgsBHMJIFE/5L8D65H+fwVcc2ovHsClX4jgX nscxt1t7HiCoI/mOO0awIB8XsxrnldJbaelAf9AGw3RObV3gMEnO42t7FGWPadc1PbsZ zkdJmYxH6zFo9A+pbt3Fgh0zw6XxQiOORpCUEHunohAV6ui04JQ8lcliSFFtlvlatUgl lVAQ== X-Gm-Message-State: AGi0PuYXsOzmBnM/HRBzbXcrJpY09mfS1Y/gDa5dNu8o40IHgH8GfNUl VZK+aQaw++RYgQwuOuPJh0u7ZO4vNdh2KGnZ315/uW+q X-Google-Smtp-Source: APiQypJVWprjK9e+phF7qCrybPf7V4Te/5KbCBwHIuN+1b18ZmVQam/pcmaQ4B+A1JRf196lghAbqW+2ISyaV4VVIUE= X-Received: by 2002:a05:6638:a47:: with SMTP id 7mr617436jap.12.1587513331119; Tue, 21 Apr 2020 16:55:31 -0700 (PDT) MIME-Version: 1.0 References: <20200421165514.C676C1CB78@freefall.freebsd.org> <54bfc0f6-be4c-349d-df87-8ba507803a04@grosbein.net> In-Reply-To: From: Ed Maste Date: Tue, 21 Apr 2020 19:55:18 -0400 Message-ID: Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-20:10.ipfw To: Eugene Grosbein Cc: "Andrey V. Elsukov" , freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 496L6X3xkJz4PDp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[48.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.46)[ip: (-6.45), ipnet: 209.85.128.0/17(-0.40), asn: 15169(-0.43), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[48.166.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 23:55:33 -0000 On Tue, 21 Apr 2020 at 18:50, Eugene Grosbein wrote: > > > I believe this is correct; what about this statement: > > > > No workaround is available. Systems not using the ipfw firewall, and > > systems that use the ipfw firewall but without any rules using "tcpoptions" > > or "tcpmss" keywords, are not affected. > > Isn't removing rules with "tcpoptions/tcpmss" considered as work-around? > > Such rules may be replaced with "ipfw netgraph" rules and processing TCP options > with NETGRAPH node ng_bpf(4). Seems as work-around to me. Fair enough, although I don't want to provide that as an official suggestion in the advisory without testing and understanding the caveats, so probably just removing the "No workaround is available." So perhaps: Systems not using the ipfw firewall, and systems that use the ipfw firewall but with no rules using "tcpoptions" or "tcpmss" keywords, are not affected. From owner-freebsd-security@freebsd.org Wed Apr 22 02:42:00 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7DF362C2C7C for ; Wed, 22 Apr 2020 02:42:00 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc14.plala.or.jp (msc14.plala.or.jp [IPv6:2400:7800:0:502e::24]) by mx1.freebsd.org (Postfix) with ESMTP id 496Ppb6lxWz4YXy for ; Wed, 22 Apr 2020 02:41:59 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from localhost ([2400:4050:9320:7a00::8]) by msc14.plala.or.jp with ESMTP id <20200422024150.WBTQ29562.msc14.plala.or.jp@localhost> for ; Wed, 22 Apr 2020 11:41:50 +0900 Date: Wed, 22 Apr 2020 11:41:40 +0900 (JST) Message-Id: <20200422.114140.1901690124008066655.ish@amail.plala.or.jp> To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:11.openssl From: Masachika ISHIZUKA In-Reply-To: <20200421165520.51D141CE03@freefall.freebsd.org> References: <20200421165520.51D141CE03@freefall.freebsd.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; mvir-ac14; Wed, 22 Apr 2020 11:41:50 +0900 X-Rspamd-Queue-Id: 496Ppb6lxWz4YXy X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 02:42:00 -0000 > # freebsd-update fetch > # freebsd-update install > # shutdown -r +10min "Rebooting for a security update" Hi. It did not update /etc/motd from 12.1R-p3 to 12.1R-p4. % uname -a FreeBSD onion.ish.org 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC amd64 % su # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 12.1-RELEASE from update1.freebsd.org... done. Fetching metadata index... done. Fetching 2 metadata patches.. done. Applying metadata patches... done. Inspecting system... done. Preparing to download files... done. Fetching 17 patches.....10... done. Applying patches... done. The following files will be updated as part of updating to 12.1-RELEASE-p4: /bin/freebsd-version /boot/kernel/ipfw.ko /usr/bin/quota /usr/lib/debug/boot/kernel/ipfw.ko.debug /usr/lib/debug/usr/bin/quota.debug /usr/lib/debug/usr/lib/libssl.so.111.debug /usr/lib/debug/usr/lib32/libssl.so.111.debug /usr/lib/libssl.a /usr/lib/libssl.so.111 /usr/lib/libssl_p.a /usr/lib32/libssl.a /usr/lib32/libssl.so.111 /usr/lib32/libssl_p.a /usr/src/crypto/openssl/ssl/t1_lib.c /usr/src/sys/conf/newvers.sh /usr/src/sys/netpfil/ipfw/ip_fw2.c /usr/src/usr.bin/quota/quota.c # freebsd-update install Installing updates...ef_read_entry failed <-- It's OK because CPU is not intel. done. # dmesg | grep CPU: CPU: AMD Turion(tm) II Neo N54L Dual-Core Processor (2196.38-MHz K8-class CPU) # reboot % uname -a FreeBSD onion.ish.org 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC amd64 % su # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 12.1-RELEASE from update2.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 12.1-RELEASE-p4. onion# uname -a FreeBSD onion.ish.org 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC amd64 -- Masachika ISHIZUKA From owner-freebsd-security@freebsd.org Wed Apr 22 07:31:31 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6D27E2A9588 for ; Wed, 22 Apr 2020 07:31:31 +0000 (UTC) (envelope-from SRS0=Wzxz=6G=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 496XDg0GXDz3LqD; Wed, 22 Apr 2020 07:31:30 +0000 (UTC) (envelope-from SRS0=Wzxz=6G=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 521DC28438; Wed, 22 Apr 2020 09:31:28 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (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 28BAF28433; Wed, 22 Apr 2020 09:31:27 +0200 (CEST) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:11.openssl To: freebsd-security@freebsd.org, FreeBSD Security Advisories References: <20200421165520.51D141CE03@freefall.freebsd.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <86c2a15b-a1d2-883a-51c7-245dcfbc1b94@quip.cz> Date: Wed, 22 Apr 2020 09:31:26 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200421165520.51D141CE03@freefall.freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 496XDg0GXDz3LqD X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 07:31:31 -0000 On 2020-04-21 18:55, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-20:11.openssl Security Advisory > The FreeBSD Project > > Topic: OpenSSL remote denial of service vulnerability > > Category: contrib > Module: openssl > Announced: 2020-04-21 > Credits: Bernd Edlinger > Affects: FreeBSD 12.1 > Corrected: 2020-04-21 15:47:58 UTC (stable/12, 12.1-STABLE) > 2020-04-21 15:53:08 UTC (releng/12.1, 12.1-RELEASE-p4) > CVE Name: CVE-2020-1967 VuXML entry indicated 11.3 as vulnerable even if original SA has Affected: 12.1 only. https://vuxml.freebsd.org/freebsd/012809ce-83f3-11ea-92ab-00163e433440.html Can you please update VuXML entry or original SA? Kind regards Miroslav Lachman From owner-freebsd-security@freebsd.org Wed Apr 22 09:07:51 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ADC2E2AD070 for ; Wed, 22 Apr 2020 09:07:51 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 496ZMn74YCz3xfM; Wed, 22 Apr 2020 09:07:49 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03M97gxd038783 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Apr 2020 09:07:43 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: emaste@freebsd.org Received: from [10.58.0.10] (dadv@dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03M97fB7078099 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2020 16:07:41 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-20:10.ipfw To: Ed Maste References: <20200421165514.C676C1CB78@freefall.freebsd.org> <54bfc0f6-be4c-349d-df87-8ba507803a04@grosbein.net> Cc: "Andrey V. Elsukov" , freebsd-security@freebsd.org From: Eugene Grosbein Message-ID: <8067db19-fee5-ce20-ab42-060c26736849@grosbein.net> Date: Wed, 22 Apr 2020 16:07:40 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 496ZMn74YCz3xfM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.89)[ip: (-5.24), ipnet: 2a01:4f8::/29(-2.64), asn: 24940(-1.54), country: DE(-0.02)]; R_SPF_PERMFAIL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 09:07:51 -0000 22.04.2020 6:55, Ed Maste wrote: > On Tue, 21 Apr 2020 at 18:50, Eugene Grosbein wrote: >> >>> I believe this is correct; what about this statement: >>> >>> No workaround is available. Systems not using the ipfw firewall, and >>> systems that use the ipfw firewall but without any rules using "tcpoptions" >>> or "tcpmss" keywords, are not affected. >> >> Isn't removing rules with "tcpoptions/tcpmss" considered as work-around? >> >> Such rules may be replaced with "ipfw netgraph" rules and processing TCP options >> with NETGRAPH node ng_bpf(4). Seems as work-around to me. > > Fair enough, although I don't want to provide that as an official > suggestion in the advisory without testing and understanding the > caveats, so probably just removing the "No workaround is available." > > So perhaps: > Systems not using the ipfw firewall, and systems that use the ipfw firewall > but with no rules using "tcpoptions" or "tcpmss" keywords, are not affected. I like it. From owner-freebsd-security@freebsd.org Wed Apr 22 06:10:05 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C68892C714D for ; Wed, 22 Apr 2020 06:10:05 +0000 (UTC) (envelope-from dewayne@heuristicsystems.com.au) Received: from hermes.heuristicsystems.com.au (hermes.heuristicsystems.com.au [203.41.22.115]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2560 bits) client-digest SHA256) (Client CN "hermes.heuristicsystems.com.au", Issuer "Heuristic Systems Type 4 Host CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 496VQc6p0fz3GDp; Wed, 22 Apr 2020 06:10:00 +0000 (UTC) (envelope-from dewayne@heuristicsystems.com.au) Received: from [10.0.5.3] (noddy.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.15.2/8.15.2) with ESMTPSA id 03M68Y9U092343 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 22 Apr 2020 16:08:35 +1000 (AEST) (envelope-from dewayne@heuristicsystems.com.au) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=heuristicsystems.com.au; s=hsa; t=1587535715; x=1588140516; bh=r04spOmAtcrfLUGh7eyC3OHnIRp9axxzSVurATS2gbc=; h=Subject:To:From:Cc:Message-ID:Date; b=ZLYbjWVcwJ+HcaXi52QtMqwDXWsQx357t7lAWkC1pWzCAxySeHfUyHTA61fnbyV7L aVbhvlNps0R03b2DbJhb8964pztMGjzAo3NeApfFlS/7j07UZGydDXXnwHo0WaS2gW fuwKOZNqF/KxoiW26t9kj7FqnUt4OTt4vigYLQLUH9exLMM2rAVqR X-Authentication-Warning: b3.hs: Host noddy.hs [10.0.5.3] claimed to be [10.0.5.3] Subject: Re: ASLR/PIE status in FreeBSD HEAD To: Ed Maste References: From: Dewayne Geraghty Autocrypt: addr=dewayne@heuristicsystems.com.au; prefer-encrypt=mutual; keydata= mQFNBFbOsVMBCgDfvi2PspSwoMEtFhF+aFLQKtzSA9f0dhDqthKHESdfbqxvKzhkBjvTJ5Na EgjKoKfoQTh5xuIv3HLhtDo5PeasPgQl9cPJeriqmqlS+UhY5BGYcMc1AO/TX0fsDaQz96ko at3RUW7sff/qPgVzSurk+DV5h866gPdn5Jdjohyl2F1rzRl6dnaAIyg49zlwZOnPHJGKye+B meqUCnPRglhkpNqXR3v1ulbWpfwhdNDvWT82qTG/qsFy/agjJvxwLuEBeoGc1dPWasO8Nztt 0dqf1Lpeg6SX2yJd76WVS4znt88OEbx/QL2PTJ/YtSepS68WaeKuARKPukkU+QXDep0gaLPl /TvU5xAZndNB3rYnpmoLb32pDHlrJbZUVyTMqc3J2EYM6aaizCpg4VEvVpVSqUT4D9MuREhu PeZ3SvEazQARAQABiQF3BB8BCAAhBQJWzrFTFwyAAWHe5yZt8RJL0vaU1MfDto5dBmeFAgcA AAoJEJVk7a1LmFrdy2QJ/AysDdFIMCRiaqEellprZQyEz5I/qZJEi6yRfXH813hhISFz6moh urZYLQ9SRdyMntT8W3Oc4pJc9fF9RSnY0SSQY/arZbrvsv6hKb1KtIK7P5mLS914J9buxEcJ SWeVuOuMA9aCNqg5uMu19pH5pXayORfbv+K7vFPiyllZ64ShUWZJL69vAc/TsbvMrGtG1M4P qyWCOKEiUT93zhVGQoA0aUYjMAZoyvozZCuieo4O8hkPgMz9lka+3bqQBSOB+qO4Iz+CZs0k Lw7Soga6bRqLK86DH99WjTA6Oj1r8Won+j4V9fnTDCVJoSyqdVHLySDv/lHaNu4Ia4AO4i2d shmLw03gOUvoWLJx5X01A5Zio4FvecnpZqQ0Wz5Ph9MiK3lwarfjonTOLeNGd5BpdnHu5VRC fJml7uAYeyKsD8C4tEBEZXdheW5lIEdlcmFnaHR5IDxkZXdheW5lLmdlcmFnaHR5QGNvbnNj aXVtaW50ZXJuYXRpb25hbC5jb20uYXU+iQGXBBMBCABBAhshCwsKDQkIDAcLAwIECBUKCQgL AwIBBRYDAgEAAh4BAheAFiEEC8bIxjMx+sDl4ZCClWTtrUuYWt0FAl5UUOgACgkQlWTtrUuY Wt3xZAn/W/mq5nDhLIfqxVM9GbU8rGzNsGLfnt5NCVcWlBKhgxOOw9EWkcRTMymwX9OMqwxI +te6Gvy7rG53T2xprtsQyqESZmjWcUSEPsQ9hjw4VZCL15ftBeZMYyO2T1e41UImXAlftleT 2kXCktgyAfwfCzHhFiZM8k9QMFQV1x+JukJ9xPFBgICRLsLsVNVw/R1L7KqARuws4HqXxY1J SCpO+FB4b6tWSIRKbzlb6tctdKppKbG/adVYuoK61ngvmsAzy/9OLhF8u1MNCgyFd2woOErh /zyuap8KvJZMlwAIqpjsoHyXsa0cq8A/uNQSmodwBpRsEGXCmZIZq2FJw6N+38to8C8m97q0 YWrY63VsoA6hA4A4/ywzE3EiwGvqJQBMRv2ET3TIdTyLoEIwXq2bDPU7XTZGh5UZEsKFMHH5 228= Cc: freebsd-security@freebsd.org Message-ID: Date: Wed, 22 Apr 2020 16:08:29 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 496VQc6p0fz3GDp X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=heuristicsystems.com.au header.s=hsa header.b=ZLYbjWVc; dmarc=none; spf=pass (mx1.freebsd.org: domain of dewayne@heuristicsystems.com.au designates 203.41.22.115 as permitted sender) smtp.mailfrom=dewayne@heuristicsystems.com.au X-Spamd-Result: default: False [-8.58 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[heuristicsystems.com.au:s=hsa]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[heuristicsystems.com.au.dwl.dnswl.org : 127.0.4.2]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[heuristicsystems.com.au]; TO_DN_SOME(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[115.22.41.203.list.dnswl.org : 127.0.4.2]; DKIM_TRACE(0.00)[heuristicsystems.com.au:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-3.38)[ip: (-9.76), ipnet: 203.40.0.0/13(-4.35), asn: 1221(-2.77), country: AU(0.01)]; ASN(0.00)[asn:1221, ipnet:203.40.0.0/13, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Wed, 22 Apr 2020 14:51:34 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 06:10:05 -0000 Thank-you for the pointer to elfctl. Unfortunately it looks like I need to create the section in the image file, due to my: (for example) # elfctl -l /usr/bin/ztest Known features are: aslr Disable ASLR protmax Disable implicit PROT_MAX stackgap Disable stack gap elfctl: NT_FREEBSD_FEATURE_CTL note not found on FreeBSD 12.1-STABLE #0 r359973M: Thu Apr 16 amd64 1201513 1201513 I had a look inside # readelf -SW /usr/bin/ztest I also looked inside /usr/share/mk/bsd.prog.mk (because it has elf hardening knobs) but no clues. Perhaps if you could provide a pointer? (Though I wonder how the new section will be inserted into some of the ports that require gcc? An adventure awaits...) Kind regards, Dewayne. PS Yes Konstantin had previously provided substantial assistance to resolve the ntpd issue. On 21/04/2020 12:00 am, Ed Maste wrote: > On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty > wrote: >> >> I'm on a similar ride. We run applications in both i386 and amd64 jails >> with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good. > > Great! > >> On the build server, the i386 jail with aslr enabled wasn't able to >> build gcc9; so this was disabled kern.elf32.*. > > i386 has little spare address space and compiling applications as PIE > has a significant performance impact there, so enabling it only on > 64-bit seems quite reasonable. > >> ntp was the only real application that didn't play nicely with aslr. >> Fortunately, this was very helpful: >> >> /usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpd... > > Yes, and you can now (if using stable/12 or -CURRENT) use elfctl to > tag the binary with a note to request randomization be disabled for > the process, although we really should address the underlying issue. > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-security@freebsd.org Wed Apr 22 20:30:26 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 381222C0279 for ; Wed, 22 Apr 2020 20:30:26 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 496sWP1gPkz3HDw for ; Wed, 22 Apr 2020 20:30:24 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: by mail-ua1-x936.google.com with SMTP id c17so3294720uae.12 for ; Wed, 22 Apr 2020 13:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tetlows.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yMOfl0ZdPw5WUxzL/w43HiRGver4k9lAeb4UhsPA+aQ=; b=IRqfLzO7EeNb6kZ10XbcC6C9l90v/ht8jXIYoKktv3aSc3iT5+97NwRO7JK/woTxUU XG6DTgMkLRn05i+uRAUYKO7G2IUSbV8iYEVikfc7WDdlpCi4RVR8uQY5hUR4BaO7ENT/ RS3PaNli33jBlfsd6I3TGFiDIamB0D6GOxT3w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yMOfl0ZdPw5WUxzL/w43HiRGver4k9lAeb4UhsPA+aQ=; b=FrWH8BzcJ8cOU3MY2lzuCf7EmtWREI6hVDUmKvwaZleq5+HU1dhPExzrP59FnEfzil D+O7mL5N/hXHhnlF39fJ0HMWiGWob5g2njV3sL34VWp1lUVSoUC1hWvpu9F1YZgxqlV4 GOnPKW3DbHeXyTXgby6KEDPbIoRle6q7UBVcvbAsRX1AOZRQkvdVij5fEt+btK5NZt6P mMjpt2sLLq97djyXl921b0Wu5//Gg3XN9IZz+Tdc61OUxGhToarOS9atvwXlRtOzOgKO PBcqog3WdanLyGO5Jlkni1qthVuMX7sGuVu3u+BGFO24kA1egHfbGQj56qtT1uUDsvmX va0g== X-Gm-Message-State: AGi0PuZa9UoXUU9+RMhNzWyi9jritn19rcZPE87Epd6REfFDc/JQM7/l wqgGED6zMMX4rUoR/r6RUxttSZT5jtf/UYKvNUCozls= X-Google-Smtp-Source: APiQypLAvU9sB91JEpa0K1occcXK9YzRzkem0tmKXvPSiWnrL/hk2hTi0cBLU1mLLMi5/UfE+erCWsi629HHzs32SH4= X-Received: by 2002:a67:ff8d:: with SMTP id v13mr570622vsq.71.1587587423924; Wed, 22 Apr 2020 13:30:23 -0700 (PDT) MIME-Version: 1.0 References: <20200421165520.51D141CE03@freefall.freebsd.org> <86c2a15b-a1d2-883a-51c7-245dcfbc1b94@quip.cz> In-Reply-To: <86c2a15b-a1d2-883a-51c7-245dcfbc1b94@quip.cz> From: Gordon Tetlow Date: Wed, 22 Apr 2020 13:30:12 -0700 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-20:11.openssl To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-security , FreeBSD Security Advisories X-Rspamd-Queue-Id: 496sWP1gPkz3HDw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tetlows.org header.s=google header.b=IRqfLzO7; dmarc=pass (policy=none) header.from=tetlows.org; spf=pass (mx1.freebsd.org: domain of gordon@tetlows.org designates 2607:f8b0:4864:20::936 as permitted sender) smtp.mailfrom=gordon@tetlows.org X-Spamd-Result: default: False [-4.03 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[tetlows.org:s=google]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tetlows.org:+]; DMARC_POLICY_ALLOW(-0.50)[tetlows.org,none]; RCVD_IN_DNSWL_NONE(0.00)[6.3.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.03)[ip: (-9.35), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 20:30:26 -0000 On Wed, Apr 22, 2020 at 12:31 AM Miroslav Lachman <000.fbsd@quip.cz> wrote: > On 2020-04-21 18:55, FreeBSD Security Advisories wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > > ============================================================================= > > FreeBSD-SA-20:11.openssl Security > Advisory > > The FreeBSD > Project > > > > Topic: OpenSSL remote denial of service vulnerability > > > > Category: contrib > > Module: openssl > > Announced: 2020-04-21 > > Credits: Bernd Edlinger > > Affects: FreeBSD 12.1 > > Corrected: 2020-04-21 15:47:58 UTC (stable/12, 12.1-STABLE) > > 2020-04-21 15:53:08 UTC (releng/12.1, 12.1-RELEASE-p4) > > CVE Name: CVE-2020-1967 > > VuXML entry indicated 11.3 as vulnerable even if original SA has > Affected: 12.1 only. > > https://vuxml.freebsd.org/freebsd/012809ce-83f3-11ea-92ab-00163e433440.html > > Can you please update VuXML entry or original SA? > I've updated VuXML to remove it. Too many copy and pastes. Thanks for the report! Gordon From owner-freebsd-security@freebsd.org Thu Apr 23 10:54:16 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5EBE12B1B12 for ; Thu, 23 Apr 2020 10:54:16 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 497Dh71Km7z4q6v for ; Thu, 23 Apr 2020 10:54:14 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-qt1-x831.google.com with SMTP id w29so4461785qtv.3 for ; Thu, 23 Apr 2020 03:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mr9qCoXxlkwxZN5NUrEaDr65bM7haVFuB6uqLOxrrZE=; b=aikn7QkycGVv2Z8C1mXIDRY5crh6+T0Yykr6yOtJek8DJzkklBohL9006JfmV6NYsA Njz8u8RAyC+15cv7mFwkwBlrpcNbn+tDZ3wa+cd88EVSU+zx3UKTl+czkZ4rGLgM9PsN tV5pJD9qHwOhQxXGVnRJonPxPVupYZHzZZCvK5I9faN2yJV0aVPoII/L1VZPnY9aHSg4 SCLmtYzQmsSSirJuBbXvxdsKEnpn66R2tI35zHHQ+rqejPpUwWNL3oQj2dms//uPskIs Uqnaqjnv9755y6T3Bsd2oLQFYX14u4T0WRP2HwEWvoaLusyCADWms5WXmL9pNItPuoRA PpRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mr9qCoXxlkwxZN5NUrEaDr65bM7haVFuB6uqLOxrrZE=; b=tmeXUNvW6NQpWKiO4TyR9ynssFZOcuSydt1SU/wIL+Yc0357srBM/o9xgQlW+V0m/T hGVe4eKeNyYVv/wl2gXYWiL38hGgNMaqBnjFCJ7R1oQ8o7FeVA2Oh/mBIMWOve2HzWjl Z8GhtEB31NsMk1WPMU+haeKwqGKbwbFd/B8R9bDUdT1ynpjoQUvXvGnOrA9JjKVlVJuD fdSkrOm+5Ca7zlwj0TvZdFym4RUkD2YwyuI3un8NlWLyXImqbl0+XBO5Io8PT64ys6Td iZ6vHYAcIli/bKdNTlAk4g1EnZEjEZga8sMEu2ig6Qv4w5gLKiGIFc2YcJuiwS6t4VG7 KTtw== X-Gm-Message-State: AGi0Puag6jUZ+Bh3f1YDL2lYRIAKyStG1vqKBIlH/316INeCzmChwqzo zprtr/aFvrLF+/8ehiwYsLoVtyCJco0k2HtpBjG1hGcY X-Google-Smtp-Source: APiQypJEz1oa9XeNEdyzLR6+wBaAzEUoFeKnqmlBjWo6E2/UcBePgZiF/UTupbij/gSz1mI/ElPYbVNyfmpRPXyvbO8= X-Received: by 2002:ac8:4e2c:: with SMTP id d12mr3259759qtw.204.1587639253887; Thu, 23 Apr 2020 03:54:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Thu, 23 Apr 2020 12:54:01 +0200 Message-ID: Subject: Re: ASLR/PIE status in FreeBSD HEAD To: Ed Maste Cc: freebsd-security@freebsd.org, Rafal Jaworowski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 497Dh71Km7z4q6v X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=aikn7Qky; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2607:f8b0:4864:20::831) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-4.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[semihalf-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.00)[ip: (-9.21), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 10:54:16 -0000 Hi Ed, Any thoughts on the questions below? Best regards, Marcin pon., 20 kwi 2020 o 16:21 Marcin Wojtas napisa=C5=82(a): > > Hi Ed, > > pt., 17 kwi 2020 o 15:52 Ed Maste napisa=C5=82(a): > > > > On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > > > > > Hi, > > > > > > Together with our customers, Semihalf is interested in improving the = status > > > of security mitigations enablement in FreeBSD. > > > > Happy to hear that there's interest in this work! > > > > > 1. Are there any hard blockers, like missing features or bugs, that p= revent > > > enabling ASLR by default in the kernel and building the base system w= ith > > > -DWITH_PIE? > > > > I believe there are no showstopper issues but there are a some > > prerequisites. One is that there are some applications that may > > misbehave with randomization enabled. They would need to be > > identified, and tagged (with the elfctl tool now in the base system). > > I was thinking if it is possible to come up with such wide test > coverage to test every single application from the base system. Do you > think it is achievable or should we rather follow the approach to do > as many tests as possible, but rely on the community feedback to catch > the corner cases (like the ntpd issue mentioned in this thread)? > What about the ports? > > > > > > 2. In case the enablement becomes eventually approved, will it be bet= ter to > > > do it for all archs or focus only on the selected ones? > > > > There's a general and increasing preference of avoiding different > > defaults per architecture. One issue though is that some options may > > have much larger performance impacts on certain architectures - e.g. > > position independent executables (PIE) on i386. > > Understood. If there is likely a performance trade-off, how about > doing tests e.g. on i386 and armv7? In case of a big drop or other > issues, could limiting ALSR/PIE to 64-bit-only be a considered > solution? > > > > > > 3. IMO it may be worth to benchmark/stress the system for the stabili= ty > > > verification and perf comparison purpose. Do you think it may be reas= onable > > > to create a kind of reference matrix (archs vs tests)? Those could be= done > > > to evaluate the current state of the OS, but also for validating each > > > proposed feature. I also think engaging the FreeBSD CI might be a hug= e help > > > in such an effort. BTW, any particular tests / benchmarks come to you= r mind > > > as useful in this case? > > > > Yes, benchmarking and testing are very important tasks on a path to > > enabling these by default. I agree with the CI comment; we should > > start with CI build + kyua runs with options turned on, in advance of > > changing the default. > > Indeed I thought of kyua and measuring buildworld execution time for > stressing the DUT and having the first comparison numbers for the low > price. > > Do you think it is possible to get help here, i.e. is there a FreeBSD > devops team, maintaining the Jenkins CI whose spare cycles could be > used for this purpose? Or is this a field requiring external help from > interested parties? > > Even before the automation, would it be useful to perform some runs on > chosen archs? > > > > > I would be interested in seeing macro-level benchmarking with > > mitigations on/off - for example, I assume Firefox must have a > > performance test suite that they use for tracking their own > > performance changes during development, and we could use benchmarks > > like that to see the impact of mitigations. Coming up with a full set > > of appropriate benchmarks will be a useful endeavour. > > Yes, making use of something actively maintained would be great. Do > you see a need for IO stressing/benchmarking for the discussed cases? > > Best regards, > Marcin From owner-freebsd-security@freebsd.org Thu Apr 23 15:38:37 2020 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C10602BA914 for ; Thu, 23 Apr 2020 15:38:37 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 497M0D58JZz3RJX; Thu, 23 Apr 2020 15:38:36 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id BD7D83C0199; Thu, 23 Apr 2020 15:38:35 +0000 (UTC) Date: Thu, 23 Apr 2020 15:38:35 +0000 From: Brooks Davis To: Marcin Wojtas Cc: Ed Maste , freebsd-security@freebsd.org, Rafal Jaworowski Subject: Re: ASLR/PIE status in FreeBSD HEAD Message-ID: <20200423153835.GF42225@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a+b56+3nqLzpiR9O" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 497M0D58JZz3RJX X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-6.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; IP_SCORE(-3.63)[ip: (-9.54), ipnet: 199.48.128.0/22(-4.76), asn: 36236(-3.80), country: US(-0.05)] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 15:38:37 -0000 --a+b56+3nqLzpiR9O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 20, 2020 at 04:21:59PM +0200, Marcin Wojtas wrote: > Hi Ed, >=20 > pt., 17 kwi 2020 o 15:52 Ed Maste napisa??(a): > > > > On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > > > > > Hi, > > > > > > Together with our customers, Semihalf is interested in improving the = status > > > of security mitigations enablement in FreeBSD. > > > > Happy to hear that there's interest in this work! > > > > > 1. Are there any hard blockers, like missing features or bugs, that p= revent > > > enabling ASLR by default in the kernel and building the base system w= ith > > > -DWITH_PIE? > > > > I believe there are no showstopper issues but there are a some > > prerequisites. One is that there are some applications that may > > misbehave with randomization enabled. They would need to be > > identified, and tagged (with the elfctl tool now in the base system). >=20 > I was thinking if it is possible to come up with such wide test > coverage to test every single application from the base system. Do you > think it is achievable or should we rather follow the approach to do > as many tests as possible, but rely on the community feedback to catch > the corner cases (like the ntpd issue mentioned in this thread)? > What about the ports? If we gate on full testing we'll never move forward. We had a GSoC project a few years ago to try to generate lame tests for each program, if someone picked that up, we could get better coverage fairly quickly, but it would still be far from complete. Our best bet is probably to make it easy for people to test and to try and recruit testers in the community (this is especially true for ports). -- Brooks --a+b56+3nqLzpiR9O Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJeobZ6AAoJEKzQXbSebgfA8bEH/2oHmEOqlyZkzVfCuSeW3d2x SitpiVCTpp040jO6eZG6d+vUlG2JydJSyO4cHvr32WLb8Mq9m1tc54PArrBrsS1d BxynlmntqU1lR0ulhTwBXyUezjqwrx8pRg32PfNbK5owU+pKAtcTwRRqqNmQr3vJ IAWe/54u2P9DUJkAUsrykc2Q4OpzSJYoTYJKnnxhN8tI1cPYuzaLmCVotmhBjX87 s+GXQWf/OuGqeM4NNj05+UIDrSuUfIOIAjDXgEwhfnN/DgxrsHv6DAiOfCXjrtSL qlYLNQrPl4ySV3HKMYr3570OSo05YQfMWzSCH6akPawCMTq5KFgi0VK3KYFRg8Y= =UUmC -----END PGP SIGNATURE----- --a+b56+3nqLzpiR9O--