Re: FreeBSD Security Advisory FreeBSD-SA-24:03.unbound

[Gordon Tetlow]

You are likely on your own here.

I’m surprised the base system kinit ever worked with OpenSSL in FIPS mode. 
Given the age of the Heimdal code (and I believe dependence on algorithms that 
should be deprecated), I would strongly suggest looking at Kerberos in ports as 
a path forward as they will likely be better supported with modern crypto.

Gordon

> On Apr 19, 2024, at 08:12, Wall, Stephen  wrote:
> 
> 
>> 
>> FreeBSD-SA-24:03.unboundSecurity Advisory
>> 
>> Topic:  Multiple vulnerabilities in unbound
> 
> Since upgrading to p6 in response to this SA, we've found that kinit has 
> started
> failing for us. This looks to be due to aaf2c7fdb8 [1], when it attempts to 
> load
> the legacy OpenSSL provider, which we do not install on our systems.
> Furthermore, it loads the default provider as well, which we specifically do 
> not
> load when systems are configured for FIPS operation.
> 
> What is our exposure if we simple revert this commit?  Are there any CVE's
> associated with it?  Is there a way to disable the ciphers at build time that
> can trigger the segfaults?
> 
> Or am I on my own resolving this because we do not use the legacy provider 
> (I.e.
> not a default system)?
> 
> Thanks for your consideration.
> 
> - Steve Wall
> 
> [1] 
> https://cgit.freebsd.org/src/commit/?h=releng/14.0=aaf2c7fdb81a1dd9de9fc77c9313f4e60e68fa76

Re: Disclosed backdoor in xz releases - FreeBSD not affected

[Gordon Tetlow]

> On Mar 29, 2024, at 11:15 AM, Shawn Webb  wrote:
> 
> On Fri, Mar 29, 2024 at 10:02:14AM -0700, Gordon Tetlow wrote:
>> FreeBSD is not affected by the recently announced backdoor included in the 
>> 5.6.0 and 5.6.1 xz releases.
>> 
>> All supported FreeBSD releases include versions of xz that predate the 
>> affected releases.
>> 
>> The main, stable/14, and stable/13 branches do include the affected version 
>> (5.6.0), but the backdoor components were excluded from the vendor import. 
>> Additionally, FreeBSD does not use the upstream's build tooling, which was a 
>> required part of the attack. Lastly, the attack specifically targeted x86_64 
>> Linux systems using glibc.
> 
> Hey Gordon,
> 
> Is there potential for Linux jails on FreeBSD systems (ie, deployments
> making use of the Linxulator) to be impacted? Assuming amd64 here,
> too.

Hard to say for certain, but I suspect the answer is yes. If the jail has the 
vulnerable software installed, there is a decent chance it would be affected. 
At that point, I would refer to the vulnerability statement published by the 
Linux distro the jail is based on. I don’t believe the vulnerability has any 
kernel dependencies that FreeBSD would provide protection.

Certainly, in the world of being conservatively cautious, I would immediately 
address any such Linux jails.

Gordon

signature.asc
Description: Message signed with OpenPGP

Disclosed backdoor in xz releases - FreeBSD not affected

[Gordon Tetlow]

FreeBSD is not affected by the recently announced backdoor included in the 
5.6.0 and 5.6.1 xz releases.

All supported FreeBSD releases include versions of xz that predate the affected 
releases.

The main, stable/14, and stable/13 branches do include the affected version 
(5.6.0), but the backdoor components were excluded from the vendor import. 
Additionally, FreeBSD does not use the upstream's build tooling, which was a 
required part of the attack. Lastly, the attack specifically targeted x86_64 
Linux systems using glibc.

The FreeBSD ports collection does not include xz/liblzma.

Reference:
https://www.openwall.com/lists/oss-security/2024/03/29/4

Best regards,
Gordon Tetlow
Hat: security-officer

signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD Security Advisory FreeBSD-SA-24:03.unbound

[Gordon Tetlow]

Per FreshPorts, the dns/unbound port was fixed on 14 Feb 2024 when it was 
upgraded to 1.19.1.

Best,
Gordon

> On Mar 28, 2024, at 2:25 AM, DutchDaemon - FreeBSD Forums Administrator 
>  wrote:
> 
> On 28-3-2024 08:51, FreeBSD Security Advisories wrote:
>> =
>> FreeBSD-SA-24:03.unbound Security Advisory
>>   The FreeBSD Project
>> 
>> Topic:  Multiple vulnerabilities in unbound
>> 
>> Category:   contrib
>> Module: unbound
>> Announced:  2024-03-28
>> Affects:FreeBSD 13.2 and FreeBSD 14.0
>> Corrected:  2024-02-17 13:45:44 UTC (stable/14, 14.0-STABLE)
>> 2024-03-28 05:06:26 UTC (releng/14.0, 14.0-RELEASE-p6)
>> 2024-02-17 13:45:44 UTC (stable/13, 13.2-STABLE)
>> 2024-03-28 05:07:55 UTC (releng/13.2, 13.2-RELEASE-p11)
>> CVE Name:   CVE-2023-50387, CVE-2023-50868
> 
> 
> What is the status of the dns/unbound port?
> 

Re: FreeBSD Security Advisory FreeBSD-SA-23:19.openssh

[Gordon Tetlow]




> On Dec 19, 2023, at 14:08, mike tancsa  wrote:
> On 12/19/2023 4:33 PM, FreeBSD Security Advisories wrote:
>> with 12.4 are encouraged to either implement the documented workaround or
>> leverage an up to date version of OpenSSH from the ports/pkg collection.
> 
> Hi,
> 
> Is the version of security/openssh-portable not vulnerable to this issue too 
> ? I dont see any update since Oct

I’ve posted a review for an update to 9.6p1: https://reviews.freebsdorg/D43132

Gordon

Re: CA's TLS Certificate Bundle in base = BAD

[Gordon Tetlow]

On Dec 3, 2022, at 5:26 PM, grarpamp  wrote:
> 
> Again, FreeBSD should not be including the bundle in base, if users
> choose to, they can get it from ports or packages or wherever else.
> Including such bundles exposes users worldwide to massive risks.
> You need to do more gpg attestation, pubkey pinning [1], tofu, and
> cert management starting from empty file... and quit trusting bundles of
> hundreds of random CA's, all of which are entities who have zero duty
> or care to the user, and often exist/corrupt/break to present evil [2] ...
> 
> [1]
> https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
> https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3
> 
> FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple option,
> thus they're incapable of securely fetching packages, iso's, etc from
> servers in re [2]. Nor does FreeBSD even post sigs over its servers pubkeys
> for users to get, verify, and pin out of band. Even pubkeys were swapped out
> on FreeBSD servers without announcing for users if any exploit or loss 
> occurred
> there or for some other reason. That's all bad news :( But can be fixed :)

Key pinning is a bad idea that 100% will cause outages.

As a thought experiment, let's suppose I (as the Security Officer) use the 
system you propose and require users to pin specific keys on our publicly 
available servers. Now let's further suppose that the project is compromised 
such that we believe those certificates might be in the hands of the attacker, 
but we aren't sure. I'm now stuck between a rock and hard place. Should I 
rotate the pinned certificate? In your proposed system, rotating that pinned 
certificate will cause massive downstream failures for all users. Since we 
aren't sure, maybe I'll leave the existing certificate in place, because I 
don't want to cause those outages since I'm not sure it's a problem.

In the publicly trusted CA system, I can easily rotate the certificate even if 
I don't believe it was compromised. It incentivizes better behavior. Also, 
please don't lecture me on the problems with the publicly trusted CA system: 
I'm very familiar with them. That said, it's the system we have and I have no 
interest in trying to tilt at that particular windmill.

In any event, nothing is preventing you from doing this on your own as the 
system ships with the tools to do so. Recognize the project has a need for 
cryptographic agility and ability to change certificates whenever we need to. 
Running our own root CA infrastructure necessary to provide a similar level of 
assurance to a professionally run CA is non-trivial and I don't believe we as a 
project are in a position (or interested) in taking on such a burden.

Gordon

Re: OpenSSL 1.1.1o in 12.3?

[Gordon Tetlow]

The only vulnerability in 1.1.1 was regarding the c_rehash script, which we 
don't ship as part of FreeBSD. As such, we didn't push it into so-maintained 
releng branches.

Best,
Gordon
Hat: security-officer

> On May 9, 2022, at 12:37 AM, Natalino Picone 
>  wrote:
> 
> Hi,
> I was looking at the latest OpenSSL CVE.
> Should this also be merged on 12.3? right now it has been done only on 13.1
> 
> https://github.com/freebsd/freebsd-src/commit/2e121bd7c73932ac52332b53ebd7824965e6a7b4
>  
> 
> 
> Thanks,
> Nat
> 
> 
> 
> Natalino Picone 
> Senior Product Security Engineer
> • Phone: +41 (0)91 647 04 06
> • natalino.pic...@nozominetworks.com 
> 
> 
> Nozomi Networks  | The 
> Leader in OT & IoT Security 
> Website  | Blog 
>  | Twitter 
>  | Linkedin |  
> YouTube 
>  | Podcast 
>   
> 
>  

Re: Lack of notification of security notices

[Gordon Tetlow]

From the secteam point of view, we haven't changed anything in the way we send 
messages to the mailing lists. I have double checked and all SAs are sent to 
the three addresses listed. I suspect this is likely fallout of the mailing 
list change over.

I can say for my part, I have gotten a copy of the messages from both the 
freebsd-announce and freebsd-security mailing lists for the SAs I have sent out 
(I'm not subscribed to the freebsd-security-notifications list). I just 
confirmed the headers for the 2 copies of SA-22:08.zlib that I received that it 
is routing through the lists. 

It does appear as though the messages are not properly archiving into the 
mailing list archives. Adding postmaster to the thread for them to dig into why 
that might be.

Gordon
Hat: security-officer

> On Apr 18, 2022, at 12:57 PM, Kevin Oberman  wrote:
> 
> As per the FreeBSD Security Information web page 
> , security notifications are sent to:
> freebsd-security-notificati...@freebsd.org 
> 
> FreeBSD-security@FreeBSD.org 
> freebsd-annou...@freebsd.org 
> This policy has lately been ignored. No postings show up in the archives of 
> freebsd-security-notificati...@freebsd.org 
>  since January. Likewise 
> for freebsd-announce. The only list showing the April 6 announcements is this 
> one, freebsd-secur...@freebad.org .
> 
> In the past, Security Announcements and Errata Notes have also been copied to 
> the stable and current lists as appropriate, although this is not mentioned.  
> This delayed the update of my systems by several days. Fortunately, only one 
> of these vulnerabilities was relevant to my systems.
> 
> Even though the announcements are almost 2 weeks old, it is still likely that 
> some people are unaware of them, so I would strongly urge that they be posted 
> to, at least, FreeBSD-Announce and  FreeBSD-Stable lists.
> 
> In passing, I will note  that the same issue appears to be occurring with 
> posts of Errata Notices.
> -- 
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com 
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Re: Important note for future FreeBSD base system OpenSSH update

[Gordon Tetlow via freebsd-security]

> On Sep 12, 2021, at 7:40 AM, Karl Denninger  wrote:
> 
> I have in the field a BUNCH of "smart" rack power strips that have this 
> problem; their management firmware does NOT support more-modern cipher sets 
> and SSL requirements.  I get it, those older SSL versions are insecure and we 
> know it.  But when the browser people all decided to kill the ability to 
> connect to such servers with no override (that is, don't warn, DENY with no 
> option to get around it) all of a sudden logging into those strips to change 
> (for example) the name of a socket, the alarm limits and similar became 
> literally impossible.  Contacting the manufacturer resulted in a middle 
> finger back; "nope, we're not releasing new firmware for that."  I've seen 
> the same thing with some older OOB management interfaces on server boards; 
> they won't take an acceptably-long (by modern standards) HTTPS server key, 
> and thus, same problem and same answer from the manufacturer.  These are 
> perfectly-serviceable devices in their application and quite-expensive to 
> replace when there's nothing
  wrong with them. On the server boards by now they've all been retired as 
people decided the better power budget and performance levels made changing 
them (and re-purchasing the RAM that went on them, which for larger servers is 
a non-trivial part of the total expense) a reasonable proposition.  This of 
course is not true for a smart power strip in the rack and makes both 
monitoring of energy and remote-hard-power-cycle available without a physical 
site visit or remote hands.

Blaming the browser and other client providers (OpenSSH, etc) for a problem 
that is 100% because the devices are now abandoned by the manufacturer is the 
wrong place to focus your anger. We have an enormous problem in the industry of 
crappy embedded devices (like the OOB management plane) accruing technical 
security debt while the manufacturers give "a middle finger back" as you say. 
The supportability of the hardware needs to be baked into the purchasing 
decision. Commitments from the manufacturers on supportability timeframes are 
important to understand and budget into a hardware refresh cycle.

> In the case of the power strips the "answer" was one of the prepackaged, 
> self-contained old "portable" versions of FireFox which complains but the 
> alert can be clicked through.  I recognize that exposing those devices to the 
> Internet is unsafe but have never trusted that anyway; they're behind a 
> gateway box with no port hole punch and if I'm VPN'd in then it's not 
> possible for a random person to screw with it.
> 
> It would be sad indeed if the only answer here is "load up a partition with 
> an older copy of FreeBSD on some device and use that."  Can we avoid that 
> being the answer, as it became with the browser issues?

You are already accepting the risk of continuing to run devices with known bad 
configurations. What's the problem with keeping that old FreeBSD host around as 
well, it's just one more risk acceptance for issues that are pretty much the 
same as what you are already accepting? Alternatively, compile and install an 
older OpenSSH version on well-maintained host in a dedicated prefix which is 
only used for that purpose.

We do need to remove the code entirely as putting it behind a compatibility or 
some other "scary things are here" flag will guarantee that manufacturers don't 
try to update their codebases to work with modern protocols; they will just 
provide instructions on how to enable scary mode and move on. In the interest 
of protecting everyone, we need to remove this code and put it into the dustbin 
of history.

Best,
Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD Security Advisory FreeBSD-SA-21:16.openssl

[Gordon Tetlow via freebsd-security]

> On Aug 25, 2021, at 8:32 AM, mike tancsa  wrote:
> 
> On 8/25/2021 11:22 AM, Gordon Tetlow wrote:
>> Hi All,
>>>Was reading the original advisory at
>>> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.openssl.org/news/secadv/20210824.txt%26source%3Dgmail-imap%26ust%3D163049755200%26usg%3DAOvVaw21BGr3aGIh9CKIH3efYzY4=gmail-imap=163051033600=AOvVaw1DOZPIolrilgltIWdl61D6
>>>  and it says
>>> 
>>> "OpenSSL versions 1.0.2y and below are affected by this [CVE-2021-3712]
>>> issue."
>>> 
>>> Does it not then impact RELENG11 ?
>>> 
>>> % openssl version
>>> OpenSSL 1.0.2u-freebsd  20 Dec 2019
>>> 
>>> I know RELENG_11 support ends in about a month, but should it not be
>>> flagged ?
>> As we don't have a support contract with OpenSSL to get access to 1.0.2 
>> patches, we could only roll the 1.1.1 patches.
> 
> Hi Gordon,
> 
> I was thinking more in terms of just a mention that RELENG_11 is
> indeed vulnerable, no ?

I hear you. We don't really have a way of doing that with our existing SA 
setup. It's oriented to releasing patches; it is not equipped to notify users 
of vulnerabilities that we do not have a patch for. Let me think on how we 
might support such a thing and discuss with the team.

Thanks,
Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD Security Advisory FreeBSD-SA-21:16.openssl

[Gordon Tetlow via freebsd-security]

> On Aug 25, 2021, at 4:59 AM, mike tancsa  wrote:
> 
> On 8/24/2021 4:53 PM, FreeBSD Security Advisories wrote:
>> 
>> Branch/path Hash Revision
>> -
>> stable/13/  9d31ae318711stable/13-n246940
>> releng/13.0/2261c814b7fa  releng/13.0-n244759
>> stable/12/r370385
>> releng/12.2/  r370396
>> -
> 
> 
> Hi All,
> 
> Was reading the original advisory at
> https://www.google.com/url?q=https://www.openssl.org/news/secadv/20210824.txt=gmail-imap=163049755200=AOvVaw21BGr3aGIh9CKIH3efYzY4
>  and it says
> 
> "OpenSSL versions 1.0.2y and below are affected by this [CVE-2021-3712]
> issue."
> 
> Does it not then impact RELENG11 ?
> 
> % openssl version
> OpenSSL 1.0.2u-freebsd  20 Dec 2019
> 
> I know RELENG_11 support ends in about a month, but should it not be
> flagged ?

As we don't have a support contract with OpenSSL to get access to 1.0.2 
patches, we could only roll the 1.1.1 patches.

Best,
Gordon
Hat: security-officer
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Wrong patch link in FreeBSD-EN-21:24.libcrypto

[Gordon Tetlow via freebsd-security]

There's always one. Thanks for the check. I've just pushed this to the
website with the corrected link. It should be corrected in the next 5-10
minutes online.

Regards,
Gordon

On Tue, Aug 24, 2021 at 2:36 PM Alan Somers  wrote:

> The just published errata notice contains a bad url.
> is: fetch https://security.FreeBSD.org/patches/EN-21:17/libcrypto.patch
> should be: https://security.FreeBSD.org/patches/EN-21:24/libcrypto.patch
>
> -Alan
>
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sysrc bug

[Gordon Tetlow via freebsd-security]

> On May 31, 2021, at 16:07, Roger Marquis  wrote:
> 
> 
>> 
>> Also, changing the root shell is bad for many reasons and I'm not
>> surprised that something doesn't work.
> 
> Surprised this old myth is still being repeated.  Having used various
> root shells in FreeBSD and other Unux/Linux systems for decades I have to
> ask specifically what said reasons are, particularly considering
> /usr/sbin/sysrc starts with "#!/bin/sh" (as does and should every system
> shell script).

It’s likely due to the quoting behavior of newlines passed as the argument when 
he ran the script, which varies between shell implementations. As I said, I’m 
not surprised something broke because many utilities are not tested with 
different shell behaviors.

I also believe if we have a reproducible test case, we should go ahead and fix 
it.

Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sysrc bug

[Gordon Tetlow via freebsd-security]

This isn't a security bug as it requires root privilege to empty
/etc/rc.conf. If you have root privilege, you can do that already.

Also, changing the root shell is bad for many reasons and I'm not
surprised that something doesn't work.

That said, it certainly is less than desirable and should probably be
more robust in case of this failure. I would recommend opening a bug
for this and see if we can get someone to pick it up.

Thanks for the report!
Gordon
Hat: security-officer

On Sat, May 29, 2021 at 11:10 PM Fas Xmut via freebsd-security
 wrote:
>
> I don't know if it is a security bug or not. When I use sysrc today, the 
> error operations emptied my /etc/rc.conf, that's a small disaster, because my 
> /etc/rc.conf is updated day by day, but now, it is empty.
>
> First, change your default root shell to sh/ksh or their derived shell. (I 
> have tested, csh will not trigger that bug).
>
> Second, backup /etc/rc.conf to any other place.
>
> Then do the following commands:
>
> 
> # sysrc something_enable="NO"
> # sysrc something_enable="YES
> > "
> awk: newline in string YES
> ... at source line 1
> something_enable: NO -> YES
> 
>
> Now see what is inside /etc/rc.conf ? Everything is empty! only one thing in 
> it:
>
> 
> something_enable="YES
> "
> 
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD Security Advisory FreeBSD-SA-21:11.smap

[Gordon Tetlow via freebsd-security]

Since I had a question on this in another forum, I figure I'll copy it to the 
public list as well. The credit line below was specifically requested by the 
reporter. It wasn't a typo or a lack of proof-reading on our part.

Best,
Gordon
Hat: security-officer

> On May 26, 2021, at 5:54 PM, FreeBSD Security Advisories 
>  wrote:
> 
> Signed PGP part
> =
> FreeBSD-SA-21:11.smap   Security Advisory
>   The FreeBSD Project
> 
> Topic:  SMAP bypass
> 
> Category:   core
> Module: amd64
> Announced:  2021-05-26
> Credits:I lost my dog if you see him please contact me at @m00nbsd.
> Affects:FreeBSD 12.2 and later.
> Corrected:  2021-05-26 19:18:54 UTC (stable/13, 13.0-STABLE)
> 2021-05-26 19:31:50 UTC (releng/13.0, 13.0-RELEASE-p1)
> 2021-05-26 19:30:31 UTC (stable/12, 12.2-STABLE)
> 2021-05-26 20:40:20 UTC (releng/12.2, 12.2-RELEASE-p7)
> CVE Name:   CVE-2021-29628
> 
> For general information regarding FreeBSD Security Advisories,
> including descriptions of the fields above, security branches, and the
> following sections, please visit https://security.FreeBSD.org/>.
> 
> I.   Background
> 
> Supervisor Mode Access Prevention (SMAP) is a security feature
> implemented by contemporary Intel and AMD CPUs.  When enabled, it
> ensures that accesses to user memory by the kernel trigger a page fault
> and a subsequent kernel panic.  This helps mitigate the security
> implications of kernel bugs that permit an attacker to read from or
> write to user memory from the kernel.
> 
> The kernel may legitimately need to copy data between userspace and the
> kernel.  To enable this, SMAP is temporarily disabled in the subroutines
> which handle this copying, so only small, specially designated portions
> of the kernel should be executed with SMAP disabled.
> 
> II.  Problem Description
> 
> The FreeBSD kernel enables SMAP during boot when the CPU reports that
> the SMAP capability is present.  Subroutines such as copyin() and
> copyout() are responsible for disabling SMAP around the sections of code
> that perform user memory accesses.
> 
> Such subroutines must handle page faults triggered when user memory is
> not mapped.  The kernel's page fault handler checks the validity of the
> fault, and if it is indeed valid it will map a page and resume copying.
> If the fault is invalid, the fault handler returns control to a
> trampoline which aborts the operation and causes an error to be
> returned.  In this second scenario, a bug in the implementation of SMAP
> support meant that SMAP would remain disabled until the thread returns
> to user mode.
> 
> III. Impact
> 
> This bug may be used to bypass the protections provided by SMAP for the
> duration of a system call.  It could thus be combined with other kernel
> bugs to craft an exploit.
> 
> IV.  Workaround
> 
> No workaround is available.  On hardware that does not implement SMAP,
> the bug is inconsequential as the mitigation does not exist in the first
> place.
> 
> 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 amd64, i386, or
> (on FreeBSD 13 and later) arm64 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-21:11/smap.patch
> # fetch https://security.FreeBSD.org/patches/SA-21:11/smap.patch.asc
> # gpg --verify smap.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
> https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
> system.
> 
> VI.  Correction details
> 
> This issue is corrected by the corresponding Git commit hash or Subversion
> revision number in the following stable and release branches:
> 
> Branch/path Hash Revision
> -
> stable/13/  876ffe28796cstable/13-n245764
> releng/13.0/f32130a1955e  releng/13.0-n244739
> stable/12/  

Re: Exim security release

[Gordon Tetlow via freebsd-security]

The port maintainer (CC'd) has already included an update for the new
Exim release. It should be available in the port system already. Pkg's
are usually built a couple of times a week.

Gordon

On Wed, May 5, 2021 at 7:02 PM Patrick via freebsd-security
 wrote:
>
> Hello, and apologies if this is not the right place to be asking this
> question.
>
> A major security release was announced yesterday by the Exim dev team
> [0]. I see some Linux distros have already released patched versions of
> Exim in their package repos. Is there any chance the FreeBSD Exim port
> will be updated to reflect these patches?
>
> Thanks,
> P
>
> [0]
> https://lists.exim.org/lurker/message/20210504.134007.ce022df3.en.html
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD Security Advisory FreeBSD-SA-21:08.vm missing in vuxml

[Gordon Tetlow via freebsd-security]

> On Apr 12, 2021, at 03:21, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> On 11/04/2021 21:49, Gian Piero Carrubba wrote:
>> * [Sun, Apr 11, 2021 at 09:36:05PM +0200] Miroslav Lachman:
 On 11/04/2021 21:21, Gian Piero Carrubba wrote:
> CCing ports-secteam@ as it seems a more appropriate recipient.
>>> 
>>> Vulnerabilities in base should be handled by core secteam, not ports 
>>> secteam.
>> The maintainer address for vuxml is ports-secteam@, so my impression is that 
>> entries in vuxml, regardless if they affect base or ports, are managed by 
>> them. Am I wrong?
> 
> Because there are entries mainly for ports and vuxml is port too. But the 
> responsible side for vulnerabilities in base is Security Officer Team. They 
> are publishing SAs, they should create and submit entries to vuxml. They are 
> almost always lacking behind, sometimes for months. I tried created patches 
> with entries in the past because I am the author of base-audit script and 
> maintainer of the port but then it was waiting for a long time to have it 
> confirmed by Security Officer Team.
> 
> I fought with this many times.

Hi there!

Secteam has been pretty faithfully putting base issues into vuxml for the past 
year at least, thanks to the tireless work by Philip. The current issues were 
committed to vuxml 6 days ago. Apparently, the backend that serves the vuxml 
for clients  hasn’t been updated for the ports git transition. There is a pr 
for that already and hopefully it will be sorted soon.

Regards,
Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Security leak: Public disclosure of user data without their consent by installing software via pkg

[Gordon Tetlow via freebsd-security]

> On Apr 7, 2021, at 7:50 PM, Stefan Blachmann  wrote:
> 

> Anything else is apparently deemed “allowed”.
> Spying out the machine and its configuration, sending that data to an
> external entity – perfectly OK. Not a problem at all.
> 
> This has been proved by the handling of this last BSDstats security
> incident, where the FreeBSD “pkg” utility is being abused to run
> spyware without the users’ pre-knowledge and without his content.
> 
> This abuse is apparently being considered acceptable by both FreeBSD
> and HardenedBSD security officers.
> Instead of taking action, you "security officers" tell the FreeBSD
> users that it is their own guilt that they got “pwnd”.
> Just because they trustingly installed software from the package repo
> hosted by FreeBSD, without religiously-carefully auditing every and
> each packages' pre- and postinstallation script before actual install,
> using the “pkg -I” option.

I do not consider it acceptable that this behavior is occurring. I'll quote to 
you what I said in my private email to you:

Running scripts at pre/post-install is a foundational design of packages. These 
scripts can do anything a shell script can do. If you are concerned packages 
running scripts, I recommend changing the pkg setting:

RUN_SCRIPTS: boolean
Run pre-/post-installation action scripts.  Default: YES.

Change this in your /usr/local/etc/pkg.conf and you will not have pre/post 
install scripts running for your packages.

Another option, instead of changing the global default is to use the pkg 
install -I switch, which will not run scripts for that installation.

As for the behavior of this specific package, I agree it is poor that it runs 
without user consent. Reading the pkg-install script, it appears it should ask 
consent, perhaps it is broken. I recommend taking it up with the port/package 
maintainer, scra...@hub.org , whom I have added to this 
email.

I agree this should be fixed and is undesirable. Even the pkg maintainer who is 
the person running the bsdstats website is in agreement here. The difference 
is: I don't assume the maintainer has ill-will and it is the result of an 
oversight that will be fixed. There is a process to be followed and I am not 
comfortable wielding the security-officer hammer unless I see visible evidence 
the process is broken and requires me to intercede. We aren't there.


> Can it be ethically acceptable to put users at risk, for example by
> intentionally (?) not setting any limits to what extent installer
> scripts are allowed to collect sensitive user and system data and
> disclose them to interested third parties?

This is an interesting point. Unfortunately, the technology we have gives 
unfettered access to the system. I'm having a hard time thinking how we could 
achieve the goal of installing software (which in our model requires root 
privileges) while also limiting what it is allowed to do on said system. I'm 
not aware of any other package system (rpm, deb, etc) that has technical limits 
on pre/post installation scripts. If you are aware of any examples, I'd love to 
see it to see if there is something we can incorporate. Patches, as always, are 
welcome to improve the system.

> This should imho be discussed in public, leading to the formulation of
> rules which might help enabling users to trust FreeBSD.
> 
> [ Just to note: the porter of the package in question wrote me that it
> never was the intention to run the scripts without user content. There
> must have happened something/some action by someone, which led to this
> behaviour. What actually happened, this can be analyzed.
> For me, what actually matters is not this particular incident, but the
> finding that spyware behavior of pre/postinstaller scripts is
> apparently generally deemed acceptable and not actionable, according
> to FreeBSD rules. So the problem are these rules, and not this last
> incident. ]

I disagree with your premise. For the record, I did take action, which was to 
escalate the problem to the port/pkg maintainer. It is their software and their 
responsibility. Please do not take my unwillingness to violate the maintainer's 
ownership of their port/pkg as unwillingness to deal with the issue. I'm would 
like the process to have a chance to work.

Lastly, your combative tone in reporting this issue is far from anything I 
would consider professional. I would ask that you give some consideration to 
your words in the hopes that you will understand that flaming me on the mailing 
list is unlikely to make me want to advocate for you.

Thanks,
Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Security leak: Public disclosure of user data without their consent by installing software via pkg

[Gordon Tetlow via freebsd-security]

On Apr 6, 2021, at 7:42 AM, Shawn Webb  wrote:
> 
> On Tue, Apr 06, 2021 at 04:39:40PM +0200, Miroslav Lachman wrote:
>> On 06/04/2021 16:27, Shawn Webb wrote:
>> 
>>> 1. BSDStats isn't run/maintained by the FreeBSD project. File the
>>>report with the BSDStats project, not FreeBSD.
>>> 2. You install a package that is made to submit statistical data.
>>> 3. You're upset that it submits statistical data?
>> 
>> The problem here is that it collects and sends data right at the install
>> time. It is really unexpected to run installed package without user consent.
>> If you install Apache, MySQL or any other package the command / daemon is no
>> run by "pkg install" command.
>> This must be avoided.
> 
> It's probably easier to submit a patch than it is to write a
> lolwut-type email. All you gotta do is rm the post-install script.
> Also `pkg install` has the -I option. But whatever, let the lolwut
> mentality prevail!

I had a conversation on the side with the requestor. In short, there is already 
a patch to address this issue in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251152 
. Not sure why it 
hasn't been committed yet, but hopefully it gets picked up shortly.

Gordon


signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD Security Advisory FreeBSD-SA-21:07.openssl

[Gordon Tetlow via freebsd-security]

Actually, I'm testing this on a 13.0-RC3 host and am not getting the p1. This 
is likely due to the freebsd-update build scripts not properly messing with the 
newvers.sh. I'll investigate. Thanks for the report!

Gordon

> On Mar 26, 2021, at 3:50 PM, Tatsuki Makino  
> wrote:
> 
> This is a fix that does not require replacing the kernel, so freebsd-update 
> does not change the kernel.
> I think the Doctor rebuilt the kernel himself/herself, so there is a -p1.
> 
> This is a frequent occurrence :)
> 
> ___
> freebsd-security@freebsd.org mailing list
> https://www.google.com/url?q=https://lists.freebsd.org/mailman/listinfo/freebsd-security=gmail-imap=161740382800=AOvVaw3Mirg5ZovHgEQvdI8Vj447
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-21:01.fsdisclosure

[Gordon Tetlow via freebsd-security]

> On Jan 31, 2021, at 7:25 AM, Andrea Venturoli  wrote:
> 
> On 1/31/21 12:29 PM, Miroslav Lachman wrote:
> 
>>> Several file systems were not properly initializing the d_off field of
>>> the dirent structures returned by VOP_READDIR.  In particular, tmpfs(5),
>>> smbfs(5), autofs(5) and mqueuefs(5) were failing to do so.  As a result,
>>> eight uninitialized kernel stack bytes may be leaked to userspace by
>>> these file systems.  This problem is not present in FreeBSD 11.
>> There is a Corrected in: stable/11, 11.4-STABLE and releng/11.4, 
>> 11.4-RELEASE-p7, but later is a statement "This problem is not present in 
>> FreeBSD 11".
>> What is true? Is it fixed in newer patchlevel of FreeBSD 11.4 or it was not 
>> present in 11.x at all?
> 
> My understanding is that the problem described in that paragraph does not 
> affect 11.x, but the next one does (and is "Corrected...").
> 
> I.e. 11.x is affected by:
> 
>> Additionally, msdosfs(5) was failing to zero-fill a pair of padding
>> fields in the dirent structure, resulting in a leak of three
>> uninitialized bytes.
> 
> 
> Is that right?

This is correct. If you look at the patch cited for 11.x, it only has a fix 
applied to msdosfs(5).

Best regards,
Gordon


signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl

[Gordon Tetlow via freebsd-security]

On Sun, Dec 13, 2020 at 12:12:08PM +, John Long via freebsd-security wrote:
> Hi Guys,
> 
> What about adopting OpenBSD's libressl? I was expecting it to take a
> long time to be compatible but from my uneducated point of view it
> looks like they did an incredible job. I think everything on OpenBSD
> uses it.
> 
> I was running OpenBSD until I put FreeBSD 12.2 on a new box, so I
> haven't been looking at for a year or so.
> 
> Does anybody know if this is a viable option? Can we just link against
> libressl or is it (much) more involved than that?

As was mentioned elsewhere, LibreSSL isn't a great fit due to their very
limited support lifespan of a given release. Once a stable release is
made, that branch is only given 1 year of support. This doesn't mesh
well with FreeBSD's 5 year support lifespan of a given branch.

Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD Security Advisory FreeBSD-SA-20:33.openssl

[Gordon Tetlow via freebsd-security]

On Fri, Dec 11, 2020 at 02:35:42PM -0800, John-Mark Gurney wrote:
> Benjamin Kaduk wrote this message on Fri, Dec 11, 2020 at 12:38 -0800:
> > On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote:
> > > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at 
> > > 23:03 +:
> > > > versions included in FreeBSD 12.x.  This vulnerability is also known to
> > > > affect OpenSSL versions included in FreeBSD 11.4.  However, the OpenSSL
> > > > project is only giving patches for that version to premium support 
> > > > contract
> > > > holders.  The FreeBSD project does not have access to these patches and
> > > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x or 
> > > > leverage
> > > > up to date versions of OpenSSL in the ports/pkg system. The FreeBSD 
> > > > Project
> > > > may update this advisory to include FreeBSD 11.4 should patches become
> > > > publicly available.
> > > 
> > > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our
> > > crypto/TLS library.  1.0.2 which is in 11-stable has not had support
> > > for almost a year, and 11 is going to have almost another year of
> > > support during which time if there's another vuln, we'll again be
> > > leaving the users in a bad place.
> > 
> > To be blunt: didn't we try reevaluating already, and come up empty?
> 
> Software is not a stand still, just because in the past we didn't find
> anything, doesn't mean we won't find something this time.

I welcome a reasonable alternative to be put forward, but I'm pretty
sure there isn't one. The five year lifespan of our releases pretty much
guarantees our crypto toolkit is going to be out of support. This is the
reality we have signed up for.

LibreSSL - 1 year lifespan of stable branch.
BoringSSL - No guarantee of API/ABI stability. Actively tells people not
to use it for production use cases.

Anything other viable implementations I'm missing?

Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD Security Advisory FreeBSD-SA-20:22.sqlite

[Gordon Tetlow via freebsd-security]

> On Aug 10, 2020, at 7:21 AM, Oleksandr Kryvulia  
> wrote:
> 
> 05.08.20 20:54, FreeBSD Security Advisories пишет:
>> a) Download the relevant patch from the location below, and verify the
>> detached PGP signature using your PGP utility.
>> 
>> [FreeBSD 12.1]
>> # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.12.1.patch
>> # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.12.1.patch.asc
>> # gpg --verify sqlite.12.1.patch.asc
>> 
>> [FreeBSD 11.4]
>> # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.11.4.patch
>> # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.11.4.patch.asc
>> # gpg --verify sqlite.11.4.patch.asc
>> 
>> [FreeBSD 11.3]
>> # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.11.3.patch
>> # fetchhttps://security.FreeBSD.org/patches/SA-20:21/sqlite.11.3.patch.asc
>> # gpg --verify sqlite.11.3.patch.asc
> 
> Hi,
> there is a typo in links -please replace "SA-20:21" with "SA-20:22"

Thanks for the report. I've already updated it on the website 
(https://www.freebsd.org/security/advisories/FreeBSD-SA-20:22.sqlite.asc 
) 
based on a previous report.

Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: pkg.freebsd.org cert has expired :/

[Gordon Tetlow via freebsd-security]

pkg.freebsd.org  is a geographically distributed set 
of servers. Can you please go to https://pkg.freebsd.org/ 
 or http://pkg.freebsd.org/  
and tell us which mirror you are hitting that has an expired certificate? The 
mirror name should be on the page.

Gordon

> On Jun 18, 2020, at 2:54 PM, Lukasz via freebsd-security 
>  wrote:
> 
> Regards,
> 
> Lukasz
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD Security Advisory FreeBSD-SA-20:11.openssl

[Gordon Tetlow]

On Wed, Apr 22, 2020 at 12:31 AM Miroslav Lachman <000.f...@quip.cz> wrote:

> On 2020-04-21 18:55, FreeBSD Security Advisories wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> >
> =
> > FreeBSD-SA-20:11.opensslSecurity
> 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
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: CVE-2019-5599 SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

[Gordon Tetlow]

Sorry for the late response, only so many hours in the day.

On Tue, Jun 18, 2019 at 08:06:55PM -0400, Shawn Webb wrote:
> It appears that Netflix's advisory (as of this writing) does not
> include a timeline of events. Would FreeBSD be able to provide its
> event timeline with regards to CVE-2019-5599?

I don't generally document a timeline of events from our side. This
particular disclosure was a bit unusual as it wasn't external but
instead was an internal FreeBSD developer the security team often works
with. As such, our process was a bit out of sync with normal (as much as
we have a normal with our current processes). All of that said, we got
notice in early June, about 10 days before public disclosure.

> Were any FreeBSD derivatives given advanced notice? If so, which ones?

They were not. I would like to get to a point where we feel we could
give some sort of heads up for downstream, but we aren't there yet.

Best,
Gordon


signature.asc
Description: PGP signature

Re: CVE-2019-5599 SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

[Gordon Tetlow]

On Tue, Jun 18, 2019 at 05:34:32PM -0400, grarpamp wrote:
> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5599
> NFLX-2019-001
> 
> Date Entry Created: 20190107
> Preallocated to nothing?
> Or witheld under irresponsible disclosure thus keeping
> users vulnerable to leaks, parallel discovery, and exploit
> for at least five months more than necessary, and
> unaware thus unable to consider potential local mitigations?

Other than the inappropriate tone, there is a reasonable question here.
MITRE allocates blocks of CVEs to FreeBSD as a CNA. We can then decide
when to assign and disclose them. The 2019-01-07 date is when MITRE
allocated a block of CVEs to FreeBSD, not when they are assigned to an
issue. We generally get a block in the beginning of each year.

If you would like to have an actual discussion around disclosure
policies, I'm happy to have one, but by your tone above, I don't think
there is any reason to do so. It seems unlikely you are open to
debate in a fashion that would be productive.

Thanks,
Gordon
Hat: Security Officer
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] FreeBSD 10.4 end-of-life

[Gordon Tetlow]

On Thu, Nov 08, 2018 at 06:39:20AM +, FreeBSD Security Officer wrote:
> Dear FreeBSD community,
> 
> As of October 31, 2018, FreeBSD 10.4 reached end-of-life and is no longer
> supported by the FreeBSD Security Team.  Users of FreeBSD 10.4 are strongly
> encouraged to upgrade to a newer release as soon as possible.

I wanted to send a quick note about the tardiness of this announcement.
I apologize for not sending it out earlier. I mixed up the 11.1 EOL with
this one and thought I had sent it out already. Sorry about that.

Regards,
Gordon
Hat: FreeBSD Security Officer


signature.asc
Description: PGP signature

Re: Regarding CVE-2018-4407

[Gordon Tetlow]

On Wed, Oct 31, 2018 at 04:17:36PM +0530, syed khalid wrote:
> Hello All,
> 
> There is kernel RCE caused by a buffer overflow in Apple ICMP's
> packet-handling code. The PoC is not available but the bug details are
> mentioned here in https://lgtm.com/blog/apple_xnu_icmp_error_CVE-2018-4407.
> Will this vulnerability affects FreeBSD? Please let me know your thoughts

I've exchanged a couple of emails with the researchers and they have
confirmed the PoC they wrote for MacOS doesn't work on FreeBSD. Further
code analysis looks like we have some bounds checking in place that
probably didn't exist in the MacOS code. All that said, I've asked a
couple of networking stack folks to take a look at it further. I'll
report if anything changes with that assessment.

Regards,
Gordon Tetlow
FreeBSD Security Officer


signature.asc
Description: PGP signature

Re: Recent security patch cause reboot loop on 11.1 RELEASE

[Gordon Tetlow]

Hmm. I'm unable to reproduce the error in any of my testing scenarios.
I apologize for not being to help further. As kib advised, if you can
please post a verbose dmesg from a successful boot along with where
you believe the panic occurs on a bad boot.

Gordon

On Thu, Jun 21, 2018 at 5:13 AM, Denis Polygalov  wrote:
> Seems like I did not cc my reply to the mailing list.
> Doing it now because I found a hint which may
> lead to the cause of the reboot loop.
>
> Removing:
>
> linux_load="YES"
> linprocfs_load="YES"
> linsysfs_load="YES"
>
> prevent the reboot loop in multi-user mode but
> leave me without Linux emulation...
>
> Regards,
> Denis.
>
>> Hi Gordon,
>>
>> this is real hardware. I found the reason (see below).
>> Setting hw.lazy_fpu_switch=1 in  /boot/loader.conf makes no difference.
>> No panic messages.
>> I can tell you when it happen. Here is the boot messages:
>> ... skipped ...
>> Timecounters tick every 1.000 msec
>> nvme cam probe device init
>> ugen2.1:  at usbus2
>> ugen1.1:  at usbus1
>> ugen0.1:  at usbus0
>> uhub0:  on usbus2
>> uhub1:  on usbus0
>> uhub2:  on usbus1
>> uhub1: 2 ports with 2 removable, self powered
>> uhub2: 2 ports with 2 removable, self powered
>> uhub0: 4 ports with 4 removable, self powered
>>
>> < here screen (local monitor) goes black and machine restarted.
>>
>> ada0 at ata2 bus 0 scbus8 target 0 lun 0
>> ada0:  ATA8-ACS SATA 3.x device
>> ada0: Serial Number WD-WMC1P0D1KEHJ
>> ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
>> ada0: 1907729MB (3907029168 512 byte sectors)
>> da0 at ciss0 bus 0 scbus0 target 0 lun 0
>> da0:  Fixed Direct Access SCSI device
>> da0: 135.168MB/s transfers
>> da0: Command Queueing enabled
>> da0: 858293MB (1757784604 512 byte sectors)
>> Trying to mount root from ufs:/dev/da0s1a [rw]...
>>
>> I noticed that I can boot the *patched* kernel in single user mode.
>> Removing these 3 lines from the /boot/loader.conf fixed rebooting loop
>> problem:
>>
>> linux_load="YES"
>> linprocfs_load="YES"
>> linsysfs_load="YES"
>>
>> This machine is used as a test bench to test stuff
>> before deploying on a production server.
>> We need Linux emulation support on the production
>> server to run closed source software...
>> So... maybe this will help someone.
>>
>> Blaming evil penguins,
>> Denis
>
>
>
>
> On 21/06/2018 4:19 PM, Gordon Tetlow wrote:
>>
>> On Wed, Jun 20, 2018 at 11:14 PM, Denis Polygalov 
>> wrote:
>>>
>>> What I did is following:
>>>
>>> # uname -a
>>> FreeBSD my_host_name 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue
>>> May  8 05:21:56 UTC 2018
>>> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>>>
>>> # freebsd-update fetch
>>> Looking up update.FreeBSD.org mirrors... 3 mirrors found.
>>> Fetching metadata signature for 11.1-RELEASE from update6.freebsd.org...
>>> done.
>>> Fetching metadata index... done.
>>> Inspecting system... done.
>>> Preparing to download files... done.
>>>
>>> The following files will be updated as part of updating to
>>> 11.1-RELEASE-p11:
>>> /boot/kernel/kernel
>>>
>>> Installing this update cause endless reboot loop.
>>>
>>> # cat /boot/loader.conf
>>> kern.maxfiles="32768"
>>> zfs_load="YES"
>>> linux_load="YES"
>>> linprocfs_load="YES"
>>> linsysfs_load="YES"
>>>
>>> # dmesg |grep CPU
>>> CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.19-MHz K8-class CPU)
>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>>> SMP: AP CPU #1 Launched!
>>> SMP: AP CPU #3 Launched!
>>> SMP: AP CPU #2 Launched!
>>> cpu0:  on acpi0
>>> cpu1:  on acpi0
>>> cpu2:  on acpi0
>>> cpu3:  on acpi0
>>> acpi_perf0:  on cpu0
>>> est: CPU supports Enhanced Speedstep, but is not recognized.
>>> est: CPU supports Enhanced Speedstep, but is not recognized.
>>> est: CPU supports Enhanced Speedstep, but is not recognized.
>>>
>>> The machine is HP ProLiant ML350
>>
>>
>> Sorry to hear you are having a problem.
>>
>> Just to confirm, this is running on hardware and not on a Xen
>> hypervisor, correct?
>>
>> Assuming it's running directly on the hardware, can you see if setting:
>> hw.lazy_fpu_switch=1
>> in /boot/loader.conf makes any difference?
>>
>> Is there any panic message?
>>
>> Thanks,
>> Gordon
>>
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Recent security patch cause reboot loop on 11.1 RELEASE

[Gordon Tetlow]

On Wed, Jun 20, 2018 at 11:14 PM, Denis Polygalov  wrote:
> What I did is following:
>
> # uname -a
> FreeBSD my_host_name 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue
> May  8 05:21:56 UTC 2018
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>
> # freebsd-update fetch
> Looking up update.FreeBSD.org mirrors... 3 mirrors found.
> Fetching metadata signature for 11.1-RELEASE from update6.freebsd.org... done.
> Fetching metadata index... done.
> Inspecting system... done.
> Preparing to download files... done.
>
> The following files will be updated as part of updating to 11.1-RELEASE-p11:
> /boot/kernel/kernel
>
> Installing this update cause endless reboot loop.
>
> # cat /boot/loader.conf
> kern.maxfiles="32768"
> zfs_load="YES"
> linux_load="YES"
> linprocfs_load="YES"
> linsysfs_load="YES"
>
> # dmesg |grep CPU
> CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.19-MHz K8-class CPU)
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> SMP: AP CPU #1 Launched!
> SMP: AP CPU #3 Launched!
> SMP: AP CPU #2 Launched!
> cpu0:  on acpi0
> cpu1:  on acpi0
> cpu2:  on acpi0
> cpu3:  on acpi0
> acpi_perf0:  on cpu0
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: CPU supports Enhanced Speedstep, but is not recognized.
> est: CPU supports Enhanced Speedstep, but is not recognized.
>
> The machine is HP ProLiant ML350

Sorry to hear you are having a problem.

Just to confirm, this is running on hardware and not on a Xen
hypervisor, correct?

Assuming it's running directly on the hardware, can you see if setting:
hw.lazy_fpu_switch=1
in /boot/loader.conf makes any difference?

Is there any panic message?

Thanks,
Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Lazy FPU State Restore

[Gordon Tetlow]

Dear FreeBSD community,

Intel has recently announced a side-channel information disclosure via
floating point unit (FPU) context switch. This issue has been assigned
CVE-2018-3665. It is our understanding this issue affects a subset of
Intel processors. More information is available directly from Intel:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00145.html

We have addressed this issue with a recent commit to 12-CURRENT for
the 64-bit x86 architecture (FreeBSD/amd64):
https://svnweb.freebsd.org/changeset/base/335072

Further commits will be forthcoming for stable branches along with an
additional patch to remediate this issue for i386. We also intend to
merge this to the currently supported releases and will issue an update
in the near future.

FreeBSD Security Team


signature.asc
Description: PGP signature

Re: FreeBSD Security Advisory FreeBSD-SA-18:03.speculative_execution

[Gordon Tetlow]

I want to send a follow up on what's going on with the Spectre/Meltdown. I 
know we have been pretty silent on this recently as the work has been 
ongoing in the background.

Info about the current patch

What we have so far is CURRENT, 11-STABLE, and 11.1-RELEASE on amd64 now 
covered with Meltdown. No user interaction is needed to use PTI as it is on 
by default. If you don't want to pay the performance cost, you should put 
vm.pmap.pti=0 into your loader.conf.

Spectre V2 coverage requires work on the user to enable. This isn't clear 
in the SA, so I will likely issue a revision to show what is needed.

Spectre V2 is mitigated via IBRS if the user has all of the following:
- Installed the 11.1-RELEASE-p8 update
- Installed an updated microcode for the CPU to support IBRS
- Changed the sysctl hw.ibrs_disable to 0

The microcode can be installed either via a BIOS update (assuming your
manufacturer has issued one including updated microcode) or via the
sysutils/devcpu-data port/pkg. This was just updated to 1.16 to include
the required microcode for many microarchitectures (but not all).
The only way to tell for sure is to look at dmesg for:
  Structured Extended Features3
which should contain IBPB and STIBP if the CPU supports IBRS. If all of
these conditions are true, check the sysctl hw.ibrs_active to see if
IBRS is turned on.

IBRS is only one way to mitigate the Spectre V2 variant. The other more
preferable way, called retpoline, has less performance impact to the
system than IBRS. However, the changes are all in the compiler which
have yet to be backported and tested with the versions of clang in 11.x
and 10.x. We wanted to get something out to allow our users to protect
themselves while the retpoline patches are finalized. Bear in mind IBRS
may have a significant impact on system performance depending on your
CPU family and workload. Users should test to decide if enabling IBRS
makes sense for their workload and tolerance for risk.

The plan for 10.x
=
As cited in the advisory, we are working on porting the changes to 10.x for 
amd64. Due to the changes in the vm system between 10.x and 11.x this is a 
fair bit of work.

The plan for i386
=
i386 is delayed as the changes needed to support PTI are more
complicated than they were on amd64. There is a high likelihood we will
fix this only in 11.x and the hope is to have it in place for the 11.2
release coming out this summer.

Gordon

On Tue, Mar 13, 2018 at 9:29 PM, FreeBSD Security Advisories
 wrote:

> ===
> FreeBSD-SA-18:03.speculative_executionSecurity Advisory
> The FreeBSD Project
>
> Topic:Speculative Execution Vulnerabilities
>
> Category: core
> Module:   kernel
> Announced:2018-03-14
> Credits:  Jann Horn (Google Project Zero); Werner Haas, Thomas
>   Prescher (Cyberus Technology); Daniel Gruss, Moritz Lipp,
>   Stefan Mangard, Michael Schwarz (Graz University of
>   Technology); Paul Kocher; Daniel Genkin (University of
>   Pennsylvania and University of Maryland), Mike Hamburg
>   (Rambus); Yuval Yarom (University of Adelaide and Data6)
> Affects:  All supported versions of FreeBSD.
> Corrected:2018-02-17 18:00:01 UTC (stable/11, 11.1-STABLE)
>   2018-03-14 04:00:00 UTC (releng/11.1, 11.1-RELEASE-p8)
> CVE Name: CVE-2017-5715, CVE-2017-5754
>
> Special Note: Speculative execution vulnerability mitigation is a work
>   in progress.  This advisory addresses the most significant
>   issues for FreeBSD 11.1 on amd64 CPUs.  We expect to update
>   this advisory to include 10.x for amd64 CPUs.  Future FreeBSD
>   releases will address this issue on i386 and other CPUs.
>   freebsd-update will include changes on i386 as part of this
>   update due to common code changes shared between amd64 and
>   i386, however it contains no functional changes for i386 (in
>   particular, it does not mitigate the issue on i386).
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:03.speculative_execution

[Gordon Tetlow]

The Special Note in the advisory discusses this:

Special Note:   Speculative execution vulnerability mitigation is a work
in progress.  This advisory addresses the most significant
issues for FreeBSD 11.1 on amd64 CPUs.  We expect to update
this advisory to include 10.x for amd64 CPUs.  Future
FreeBSD
releases will address this issue on i386 and other CPUs.
freebsd-update will include changes on i386 as part of this
update due to common code changes shared between amd64 and
i386, however it contains no functional changes for i386 (in
particular, it does not mitigate the issue on i386).

On Wed, Mar 14, 2018 at 7:06 AM, Mike Tancsa  wrote:

> On 3/14/2018 12:29 AM, FreeBSD Security Advisories wrote:
> > Affects:All supported versions of FreeBSD.
> > Corrected:  2018-02-17 18:00:01 UTC (stable/11, 11.1-STABLE)
> > 2018-03-14 04:00:00 UTC (releng/11.1, 11.1-RELEASE-p8)
>
> Hi,
> Are these corrections just AMD64 ? Or does it fix it on i386 as
> well ?
>
> ---Mike
>
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

[Gordon Tetlow]

Sorry about that. I thought I had everything but I missed that piece. They 
should be coming shortly.

That said, I’m seeing reports of the ipsec patches for 10.x not compiling. Will 
look into that shortly. 

Gordon

> On Mar 7, 2018, at 06:40, Philip M. Gollucci  wrote:
> 
> The links are 404ing
> 
> On Wed, Mar 7, 2018 at 2:10 AM, FreeBSD Security Advisories <
> security-advisor...@freebsd.org> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> 
>> =
>> FreeBSD-SA-18:02.ntpSecurity
>> Advisory
>>  The FreeBSD
>> Project
>> 
>> Topic:  Multiple vulnerabilities of ntp
>> 
>> Category:   contrib
>> Module: ntp
>> Announced:  2018-03-07
>> Credits:Network Time Foundation
>> Affects:All supported versions of FreeBSD.
>> Corrected:  2018-02-28 09:01:03 UTC (stable/11, 11.1-STABLE)
>>2018-03-07 05:58:24 UTC (releng/11.1, 11.1-RELEASE-p7)
>>2018-03-01 04:06:49 UTC (stable/10, 10.4-STABLE)
>>2018-03-07 05:58:24 UTC (releng/10.4, 10.4-RELEASE-p6)
>>2018-03-07 05:58:24 UTC (releng/10.3, 10.3-RELEASE-p27)
>> CVE Name:   CVE-2018-7182, CVE-2018-7170, CVE-2018-7184, CVE-2018-7185,
>>CVE-2018-7183
>> 
>> 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
>> 
>> The ctl_getitem() function is used by ntpd(8) to process incoming "mode 6"
>> packets.  A malicious "mode 6" packet can be sent to an ntpd instance, and
>> if the ntpd instance is from 4.2.8p6 through 4.2.8p10, ctl_getitem() will
>> read past the end of its buffer. [CVE-2018-7182]
>> 
>> The ntpd(8) service can be vulnerable to Sybil attacks.  If a system is
>> configured to use a trustedkey and if one is not using the feature
>> introduced
>> in ntp-4.2.8p6 allowing an optional 4th field in the ntp.keys file to
>> specify
>> which IPs can serve time, a malicious authenticated peer, i.e., one where
>> the
>> attacker knows the private symmetric key, can create arbitrarily-many
>> ephemeral associations in order to win the clock selection of ntpd and
>> modify
>> a victim's clock. [CVE-2018-7170]
>> 
>> The fix for NtpBug2952 was incomplete, and while it fixed one problem it
>> created another.  Specifically, it drops bad packets before updating the
>> "received" timestamp.  This means a third-party can inject a packet with
>> a zero-origin timestamp, meaning the sender wants to reset the association,
>> and the transmit timestamp in this bogus packet will be saved as the most
>> recent "received" timestamp.  The real remote peer does not know this
>> value and this will disrupt the association until the association resets.
>> [CVE-2018-7184]
>> 
>> The NTP Protocol allows for both non-authenticated and authenticated
>> associations, in client/server, symmetric (peer), and several broadcast
>> modes.  In addition to the basic NTP operational modes, symmetric mode and
>> broadcast servers can support an interleaved mode of operation.  In
>> ntp-4.2.8p4, a bug was inadvertently introduced into the protocol engine
>> that
>> allows a non-authenticated zero-origin (reset) packet to reset an
>> authenticated interleaved peer association.  If an attacker can send a
>> packet
>> with a zero-origin timestamp and the source IP address of the "other side"
>> of
>> an interleaved association, the 'victim' ntpd will reset its association.
>> The attacker must continue sending these packets in order to maintain the
>> disruption of the association.  [CVE-2018-7185]
>> 
>> The ntpq(8) utility is a monitoring and control program for ntpd.  The
>> internal decodearr() function of ntpq(8) that is used to decode an array in
>> a response string when formatted data is being displayed.  This is a
>> problem
>> in affected versions of ntpq if a maliciously-altered ntpd returns an array
>> result that will trip this bug, or if a bad actor is able to read an
>> ntpq(8)
>> request on its way to a remote ntpd server and forge and send a response
>> before the remote ntpd sends its response.  It is potentially possible that
>> the malicious data could become injectable/executable code. [CVE-2017-7183]
>> 
>> III. Impact
>> 
>> Malicious remote attackers may be able to break time synchornization,
>> or cause the ntpq(8) utility to crash.
>> 
>> IV.  Workaround
>> 
>> No workaround is available, but systems not running ntpd(8) or ntpq(8) are
>> not affected.  Network 

Re: Response to Meltdown and Spectre

[Gordon Tetlow]

On Tue, Jan 16, 2018 at 1:57 AM, Konstantin Belousov
<kostik...@gmail.com> wrote:
> On Mon, Jan 15, 2018 at 09:20:24PM -0800, Gordon Tetlow wrote:
>> On Sat, Jan 13, 2018 at 8:10 AM, Konstantin Belousov
>> <kostik...@gmail.com> wrote:
>> > On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
>> >> Meltdown (CVE-2017-5754)
>> >> 
>> >> Initial work can be tracked at https://reviews.freebsd.org/D13797.
>> >> Please note this is a work in progress and some stuff is likely to be
>> >> broken.
>> > I consider this patch as ready for review now.
>>
>> Awesome! So, what's next? Do we have some testers we can solicit to
>> beat on this? I believe des@ had a test case to try out? Based on
>> where we are, what needs to be done to get this into the tree?
>> Secondarily, what's needed to get this in shape for 10.3/10.4/11.1?
>
> As expected, nothing happens WRT review.

Who is a good person to review this? alc? (I can't think of any other
VM people out there).

> Peter tested the patch, it seems to be fine. I put shims to allow i386
> to compile. My idea is to flip the default to non-PTI and commit the
> patch as is today.

Is there a reason to leave the PTI off in CURRENT? I'd rather turn it
on and break some stuff to get the testing coverage than to leave it
off.

Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Response to Meltdown and Spectre

[Gordon Tetlow]

On Sat, Jan 13, 2018 at 8:10 AM, Konstantin Belousov
<kostik...@gmail.com> wrote:
> On Mon, Jan 08, 2018 at 09:57:51AM -0800, Gordon Tetlow wrote:
>> Meltdown (CVE-2017-5754)
>> 
>> Initial work can be tracked at https://reviews.freebsd.org/D13797.
>> Please note this is a work in progress and some stuff is likely to be
>> broken.
> I consider this patch as ready for review now.

Awesome! So, what's next? Do we have some testers we can solicit to
beat on this? I believe des@ had a test case to try out? Based on
where we are, what needs to be done to get this into the tree?
Secondarily, what's needed to get this in shape for 10.3/10.4/11.1?

Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Response to Meltdown and Spectre

[Gordon Tetlow]

By now, we're sure most everyone have heard of the Meltdown and Spectre
attacks. If not, head over to https://meltdownattack.com/ and get an
overview. Additional technical details are available from Google
Project Zero.
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

The FreeBSD Security Team was notified of the issue in late December
and received a briefing under NDA with the original embargo date of
January 9th. Since we received relatively late notice of the issue, our
ability to provide fixes is delayed.

Meltdown (CVE-2017-5754)

In terms of priority, the first step is to mitigate against the Meltdown
attack (CVE-2017-5754, cited as variant 3 by Project Zero). Work for
this is ongoing, but due to the relatively large changes needed, this is
going to take a little while. We are currently targeting patches for
amd64 being dev complete this week with testing probably running into
next week. From there, we hope to give it a short bake time before
pushing it into the 11.1-RELEASE branch. Additional work will be
required to bring the mitigation to 10.3-RELEASE and 10.4-RELEASE.

The code will be selectable via a tunable which will automatically turn
on for modern Intel processors and off for AMD processors (since they
are reportedly not vulnerable). Since the fix for Meltdown does incur a
performance hit for any transition between user space and kernel space,
this could be rather impactful depending on the workload. As such, the
tunable can also be overridden by the end-user if they are willing to
accept the risk.

Initial work can be tracked at https://reviews.freebsd.org/D13797.
Please note this is a work in progress and some stuff is likely to be
broken.

Spectre (CVE-2017-5753 and CVE-2017-5715)
~
When it comes to the Spectre vulnerabilities, it is much harder to sort
these out. Variant 1 (CVE-2017-5753) is going to require some static
analysis to determine vulnerable use cases that will require barriers to
stop speculation from disclosing information it shouldn't. While we
haven't done the analysis to determine where we are vulnerable, the
number of cases here are supposed to be pretty small. Apparently there
have been some Coverity rules developed to help look for these, but we
are still evaluating what can be done here.

The other half of Spectre, variant 2 (CVE-2017-5715) is a bit trickier
as it affects both normal processes and bhyve. There is a proposed patch
for LLVM (https://reviews.llvm.org/D41723) that introduces a concept
called 'retpoline' which mitigates this issue. We are likely to pull
this into HEAD and 11-STABLE once it hits the LLVM tree. Unfortunately,
the currently supported FreeBSD releases are using older versions of
LLVM for which we are not sure the LLVM project will produce patches. We
will be looking at the feasibility to backport these patches to these
earlier versions.

There are CPU microcode fixes coming out when in concert with OS changes
would also help, but that's a bit down the road at the moment.


If anything significantly changes I will make additional posts to
clarify as the information becomes available.

Best regards,
Gordon Tetlow
with security-officer hat on


signature.asc
Description: PGP signature

Re: clang way to patch for Spectre?

[Gordon Tetlow]

On Thu, Jan 4, 2018 at 10:49 AM, Julian Elischer  wrote:
> On 5/1/18 12:02 am, Lev Serebryakov wrote:
>>
>> Hello Freebsd-security,
>>
>> https://reviews.llvm.org/D41723
>>
>>
> not really..
>
> What's to stop an unprivileged used bringing his own compiler? or a
> precompiled binary?

If I'm reading this right (and there is a good chance I'm not), since
unprivileged users don't bring the kernel or system libraries to the
system, the mitigations would still work.

Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Gordon Tetlow]

On Wed, Dec 13, 2017 at 01:29:26PM -0800, Peter Wemm wrote:
> On 12/12/17 5:38 PM, Yuri wrote:
> > On 12/12/17 16:37, Peter Wemm wrote:
> >> I think you're missing the point.  It is a sad reality that SSL/TLS 
> >> corporate
> >> (and ISP) MITM exists and is enforced on a larger scale than we'd like.  
> >> But
> >> it is there, and when mandated/enforced you have to go through the MITM
> >> appliance, or not connect at all.  Private CA's generally break those
> >> appliances - an unfortunate FreeBSD user in this situation is cut off.  
> >> How is
> >> this better?
> > 
> > 
> > This is certainly better for users because it informs the user. Now he has 
> > a choice to use a special override key to use MITMed https anyway or 
> > refuse, vs. with http he is not informed.
> 
> You misunderstand the problem.
> 
> A well-behaving corporate with TLS MITM will *block* connections to the 
> freebsd-ca signed services as they will fail it's validation.
> 
> The user is left with:
>   * can't connect on 443 (proxy blocks failed validations), or
>   * can't connect on 80 (because you don't like people having options).
> .. which leads to stop using FreeBSD.

I'm going to put my SO hat on here for a second, put on the flame
retardant suit, and make the following statement:

I want to move the default for svn to be HTTPS. This would mean setting
up a redirect on http://svn.freebsd.org -> https://svn.freebsd.org. For
those people that are unable (for whatever reason) to use HTTPS, we can
make a vhost they are able to use HTTP on. I would suggest something
like: http://i-love-waffles-and-svn-over-http.freebsd.org. (Waffles are
awesome.) The CA for this HTTPS server should be the standard publicly
trusted CA we use for everything (Let's Encrypt).

We can debate the brokeness of the current CA system (and I completely
agree there is a ton of brokeness there), but it is the system we have
today. We should follow industry best practice here.

Running a Root CA brings a huge amount of baggage and we are not mature
enough in policy to build in a manner that would align with established
practice for running a Root CA.

Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Gordon Tetlow]

On Tue, Dec 05, 2017 at 11:18:45PM +, RW via freebsd-security wrote:
> On Tue, 5 Dec 2017 14:08:49 -0800
> Gordon Tetlow wrote:
> 
> 
> > Using this as a reason to not move to HTTPS is a fallacy. We should do
> > everything we can to help our end-users get FreeBSD in the most secure
> > way.
> 
> I think it's more a question of whether all users should be forced onto
> https even if it might prevent some users from getting security updates.

I agree with this sentiment. I would like https to be the default with
http being an explicit decision on the user's end to use. This way, the
naive user can get the benefits of encryption in transit while a
knowledgable user can accept the risk of getting updates via http.

Best,
Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Gordon Tetlow]

> On Dec 5, 2017, at 14:43, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:
> 
> 
> In message <20171205220849.gh9...@gmail.com>, Gordon Tetlow writes:
> 
>> Using this as a reason to not move to HTTPS is a fallacy. We should do
>> everything we can to help our end-users get FreeBSD in the most secure
>> way.
> 
> The vastly oversold "security" of HTTPS is entirely borrowed from
> a confederation of root-CA's which no non-deluded person can ever
> seriously trust.

Assertion of identity and encryption in transit are separate issues. I do agree 
that identity is fundamentally broken with the existing CA system. I’m more 
interested in preventing tampering of data in transit. HTTPS is an easy way to 
do that.

Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Gordon Tetlow]

On Wed, Dec 06, 2017 at 08:55:00AM +1100, Dewayne Geraghty wrote:
> On 6/12/2017 8:13 AM, Yuri wrote:
> > On 12/05/17 13:04, Eugene Grosbein wrote:
> >> It is illusion that https is more secure than unencrypted http in a
> >> sense of MITM
> >> just because of encryption, it is not.
> >
> >
> > It *is* more secure. In order to break it, you have to have
> > compromized https authorities. Some state actors have plausibly done
> > this. http, on the contrary, can be altered by anybody who has access
> > to the wire, which is generally a much wider set.
> >
> >
> > Yuri 
> 
> Yuri,
> It can be illusory.   My last job was as Sec Mgr for a large bank.  They
> disabled cert checking on client devices, placed a wildcard cert at the
> internet boundary and captured all https unencrypted.  An alternative
> approach to advocate is dnssec.  :)

That's a specific decision made by a business as to how they are going
to run their end-points. We can never help in that scenario.

Using this as a reason to not move to HTTPS is a fallacy. We should do
everything we can to help our end-users get FreeBSD in the most secure
way.

Regards,
Gordon
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: New Security Officer

[Gordon Tetlow]

On Sun, Nov 05, 2017 at 11:50:55PM -0800, Xin Li wrote:
> (bcc'ed to core@, developers@)
> 
> Hello all,
> 
> I'm very please to announce that Gordon Tetlow (gordon@) has offered to
> take over as FreeBSD Security Officer, which the FreeBSD Core Team has
> approved.  Over the last few months, we have worked through the daily
> work for Security Officer tasks, and we feel confident that he will be a
> great Security Officer.
> 
> Therefore, effective immediately, I'm stepping down as security officer.
>  I'll stay on the FreeBSD security team as Security Officer Emeritus for
> the time being.
> 
> I would like to also take this opportunity to thank the current and
> previous members of the security team for their work during the last 3
> years.  Among these members, I'd like to specifically thank Gleb
> Smirnoff, who have been critical for the success of the team in 2016 and
> have contributed more than myself in drafting the advisories and ran
> everything with me when my availability have reduced; Glen Barber for
> his support from both clusteradm@ and re@ side and have worked on
> various freebsd-update builds for new FreeBSD releases and his
> contribution to the advisory drafts; and Remko Lodder who have worked as
> the secretary, helped with the advisories, and responded outside
> researchers in a timely manner.
> 
> Thank you for all the support and bug reports you've provided over the
> years, and please join me in welcoming Gordon to his new role.

I'd like to take this opportunity to thank Xin for running the security
team for the past few years. It's a demanding role and I hope I can rise
to the occasion for what is in front of me.

I would also like to announce that Gleb has also decided it is time for
him to step down from the security team. I'd like to additionally thank
him for his insight and work over the past year or so I've been involved
with the security team.

This past summer, Ed Maste volunteered to serve as a Deputy Security
Officer and we don't let a good volunteer get away once they have
stepped up. As such, I'll be onboarding Ed into the team ASAP to get him
up to speed as quickly as possible.

Lastly, I'd like to echo Xin's note about Remko. He's been a steadfast
secretary and I don't think I could be successful at this new role
without him there to help make sure many of the details are handled.

Regards,
Gordon


signature.asc
Description: PGP signature