Re: Question regarding FreeBSD-SA-22:15.ping (CVE-2022-23093)

[Ed Maste]

On Mon, 6 Mar 2023 at 08:16, András László Farkas
 wrote:
>
> Dear FreeBSD Security support team.
>
> According to your official advisory on FreeBSD-SA-22:15.ping, the affected 
> versions are "All supported versions of FreeBSD", which means in practice 
> 12.3, 12.4 and 13.1.
>
> My question.:
> Is this vulnerability present in previous FreeBSD versions as well? My 
> question mainly concerns an old EoL version, which is the 6.2.

We have not analyzed EoL versions, so cannot say whether the bug
exists in 6.2 or not.

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

[Ed Maste]

On Thu, 16 Feb 2023 at 13:48, Michael Grimm  wrote:
>
>
>
> > On 16. Feb 2023, at 19:23, FreeBSD Security Advisories 
> >  wrote:
>
> […]
>
> > Branch/path Hash Revision
> > - -
> > stable/13/  296ec8eae0c8stable/13-n260933

This is indeed an error. It should be stable/13-n254414. We'll update
the advisory soon.

Clarification on FreeBSD-SA-22:15.ping / CVE-2022-23093 ping(8) stack overflow

[Ed Maste]

We've seen many blog posts and news articles about this issue and
unfortunately most of them get the details wrong. So, to clarify:

- This issue affects only /sbin/ping, not kernel ICMP handling.
- The issue relies on receipt of malicious packet(s) while the ping
  utility is running (i.e., while pinging a host).
- ping(8) is setuid root, but drops privilege (to that of the user
  executing it) after opening sockets but before sending or receiving
  data.
- ping(8) runs in a Capsicum capability sandbox, such that even in the
  event of a compromise the attacker is quite limited (has no access to
  global namespaces, such as the filesystem).
- It is believed that exploitation is not possible due to the stack
  layout on affected platforms.

Re: FreeBSD Security Advisory FreeBSD-SA-22:15.ping

[Ed Maste]

On Thu, 1 Dec 2022 at 10:28, mike tancsa  wrote:
>
> My concern is the "evil server in the middle" ... Things like route
> highjacking are not that uncommon. I have a number of IoT devices out
> there I will need to patch, some still based on RELENG_11.

The bug was introduced after releng/11, so those ones won't be affected.

Re: Important note for future FreeBSD base system OpenSSH update

[Ed Maste]

On Thu, 9 Sept 2021 at 14:01, Ed Maste  wrote:
>
> There is an important caveat to be aware of for the next base system
> update though - I've reproduced it below (from OpenSSH's release
> notes, https://www.openssh.com/releasenotes.html).

Upstream has also made a change to have scp use the SFTP protocol by
default. This will appear in OpenSSH 8.8. You can test SFTP protocol
mode now by passing the -s flag to OpenSSH (in main/-CURRENT).

Commit message:

Author: d...@openbsd.org 
AuthorDate: Wed Sep 8 23:31:39 2021 +
Commit: Damien Miller 
CommitDate: Thu Sep 9 12:35:37 2021 +1000

upstream: Use the SFTP protocol by default. The original scp/rcp

protocol remains available via the -O flag.

Note that ~user/ prefixed paths in SFTP mode require a protocol extension
that was first shipped in OpenSSH 8.7.

ok deraadt, after baking in snaps for a while without incident
___
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"

Important note for future FreeBSD base system OpenSSH update

[Ed Maste]

We now have OpenSSH 8.7p1 in the base system and I will MFC it to
stable branches soon. (FIDO/U2F support is one of the most anticipated
new features available in this OpenSSH version, but it is not yet
enabled in the base system - additional work is ongoing.)

There is an important caveat to be aware of for the next base system
update though - I've reproduced it below (from OpenSSH's release
notes, https://www.openssh.com/releasenotes.html).

The notice includes a command to run to determine if a server will be
affected by this issue - I would appreciate it if folks can try it
with servers they use and report back, to help determine if this will
be an issue in practice and to help guide the next base system update.

Imminent deprecation notice
===

OpenSSH will disable the ssh-rsa signature scheme by default in the
next release.

In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1
hash algorithm in conjunction with the RSA public key algorithm. It is
now possible[1] to perform chosen-prefix attacks against the
SHA-1 algorithm for less than USD$50K.

Note that the deactivation of "ssh-rsa" signatures does not
necessarily require cessation of use for RSA keys. In the SSH
protocol, keys may be capable of signing using multiple algorithms. In
particular, "ssh-rsa" keys are capable of signing using "rsa-sha2-256"
(RSA/SHA256), "rsa-sha2-512" (RSA/SHA512) and "ssh-rsa" (RSA/SHA1).
Only the last of these is being turned off by default.

This algorithm is unfortunately still used widely despite the
existence of better alternatives, being the only remaining public key
signature algorithm specified by the original SSH RFCs that is still
enabled by default.

The better alternatives include:

 * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
   algorithms have the advantage of using the same key type as
   "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been
   supported since OpenSSH 7.2 and are already used by default if the
   client and server support them.

 * The RFC8709 ssh-ed25519 signature algorithm. It has been supported
   in OpenSSH since release 6.5.

 * The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These
   have been supported by OpenSSH since release 5.7.

To check whether a server is using the weak ssh-rsa public key
algorithm, for host authentication, try to connect to it after
removing the ssh-rsa algorithm from ssh(1)'s allowed list:

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

If the host key verification fails and no other supported host key
types are available, the server software on that host should be
upgraded.

OpenSSH recently enabled the UpdateHostKeys option by default to
assist the client by automatically migrating to better algorithms.

[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020)
https://eprint.iacr.org/2020/014.pdf
___
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

[Ed Maste]

On Mon, 14 Dec 2020 at 11:46, Ed Maste  wrote:
>
> On Thu, 10 Dec 2020 at 10:43, Wall, Stephen  wrote:
> >
> > > A query: am I right that the patch doesn’t bump the OpenSSL version to 
> > > 1.1.1.i ?
> >
> > That is correct.
>
> Further to that, OpenSSL 1.1.1i includes some additional, minor
> changes beyond the vulnerability fix. 1.1.1i is now in HEAD (as of
> r368472) and has been merged to stable/12.

Oops, I got ahead of myself - it has not yet been merged to stable/12.
___
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

[Ed Maste]

On Thu, 10 Dec 2020 at 10:43, Wall, Stephen  wrote:
>
> > A query: am I right that the patch doesn’t bump the OpenSSL version to 
> > 1.1.1.i ?
>
> That is correct.

Further to that, OpenSSL 1.1.1i includes some additional, minor
changes beyond the vulnerability fix. 1.1.1i is now in HEAD (as of
r368472) and has been merged to stable/12.
___
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

[Ed Maste]

On Wed, 9 Dec 2020 at 18:03, FreeBSD Security Advisories
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> =
> FreeBSD-SA-20:33.opensslSecurity Advisory
>   The FreeBSD Project
>
> Topic:  OpenSSL NULL pointer de-reference
>
> Category:   contrib
> Module: openssl
> Announced:  2020-12-08
> Affects:All supported versions of FreeBSD.
> Corrected:  2020-12-08 18:28:49 UTC (stable/12, 12.2-STABLE)
> 2020-12-08 19:10:40 UTC (releng/12.2, 12.2-RELEASE-p2)
> 2020-12-08 19:10:40 UTC (releng/12.1, 12.1-RELEASE-p12)
> CVE Name:   CVE-2020-1971
>
> Note: The OpenSSL project has published publicly available patches for
> versions included in FreeBSD 12.x.  This vulnerability is also known to
> affect OpenSSL versions included in FreeBSD 11.4.

The fix has been backported by jkim@ to stable/11 in r368530:
https://svnweb.freebsd.org/base?view=revision=368530

It can be applied to a releng/11.4 Subversion checkout by executing
(at the top of the checked-out tree):
$ svn merge -c 368530 ^/stable/11 .

I expect an updated advisory, including the 11.4 patch, to be released soon.
___
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: Improved PIE binary tooling

[Ed Maste]

On Thu, 4 Jun 2020 at 20:15, Dewayne Geraghty
 wrote:
>
> Thank-you Ed.  Though I have two questions:
>
> 1. We've recompiled all the ports I use with either -fPIC or -fPIE and
> the linker flag -pie. Is there something required for ports to utilise
> these changes, or are the changes only in the mk files affecting the
> base system build?

No additional change is needed - the linker will automatically add
this flag when -pie is specified.

> 2. I've also taken advantage of employing -fstack-clash-protection,
> unfortunately this is currently only available via gcc (we're using gcc9
> at the moment).  Does the fact that we use gcc9 and binutils 2.33.1
> influence the outcome of your changes?

Mmm, good question - the LLD commit indicated that binutils should set
this too, but I haven't tried. You can check `readelf -d` on one of
your PIE binaries, and if the flag is not set probably submit a PR
against devel/binutils.

-fstack-clash-protection is in Clang now, but it landed after 10.0.
The next Clang update will include it. (It was actually committed and
reverted four times, but stuck on the fifth try.)
___
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"

Improved PIE binary tooling

[Ed Maste]

Kostik and I recently committed a couple of changes to improve PIE
binary support:

r361725 Do not allow to load ET_DYN object with DF_1_PIE flag set.
r361740 lld: Set DF_1_PIE for -pie

Previously there could be ambiguity as to whether an object is a
shared library (DSO) or Position Independent Executable (PIE) binary;
a PIE is in fact a special type of DSO. These changes add a .dynamic
flag DF_1_PIE that's used to unambiguously indicate that an object is
a PIE binary, and disallow the use of dlopen() or DT_NEEDED on that
binary.

Future changes should have file(1) report "position independent
executable" or similar instead of "shared object". Some desktop
environments / file managers have had issues refusing to execute PIE
binaries, and tagging them should also address those.
___
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: Malicious root user sandboxing

[Ed Maste]

On Mon, 25 May 2020 at 14:00, Ihor Antonov  wrote:
>
> I was looking at Capsicumizer and it looks very interesting.
> The only reason I was hesitant is that this is an external application, not a
> FreeBSD core. Is it going to be included in FreeBSD in some distant future?

There are no explicit plans at this point and right now I would
describe it as a solid proof of concept - it works well, but only a
limited amount of functionality is supported by libpreopen. That said,
I would be very happy to see it developed further and become a
component of FreeBSD.
___
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: ASLR/PIE status in FreeBSD HEAD

[Ed Maste]

On Mon, 4 May 2020 at 19:39, Dewayne Geraghty
 wrote:
>
> It would be palatable to have a "secure.mk" under /usr/ports/Mk/Uses
> that enables  pie, relro, now, noexecstack and elfctl features.  Then
> port users can enable/disable their (elfctl) default features as they wish.

The general intent for elfctl isn't to have a lot of knobs to worry
about, either user- or developer-facing, and they'll generally be
opt-outs. Ports with known incompatibilities will be tagged at build
time (regardless of whether mitigations are enabled), and mitigations
should be able to be turned on system-wide.

We should be able to address non-executable stack in a similar way -
virtually all ports should have a RW GNU_STACK segment indicating that
the stack is not executable, so a ports build stage could check for
that and produce an error if not, with some sort of override for any
exceptional cases.

We definitely want some global infrastructure for pie, relro, and bind_now.
___
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: ASLR/PIE status in FreeBSD HEAD

[Ed Maste]

On Mon, 20 Apr 2020 at 10:22, Marcin Wojtas  wrote:
>
> 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?

There aren't a lot of spare cycles to go around, but putting
automation in place so that tests like this can easily be performed is
certainly something that's in the Jenkins team's domain.

> Yes, making use of something actively maintained would be great. Do
> you see a need for IO stressing/benchmarking for the discussed cases?

In the fullness of time I think it's important, but my opinion is that
it's really functional tests that we need, for enabling features in
-CURRENT; we can work on benchmarking before and after changing a
default.
___
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: ASLR/PIE status in FreeBSD HEAD

[Ed Maste]

On Wed, 22 Apr 2020 at 02:10, Dewayne Geraghty
 wrote:
>
> 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:
> aslrDisable ASLR
> protmax Disable implicit PROT_MAX
> stackgapDisable stack gap
> elfctl: NT_FREEBSD_FEATURE_CTL note not found
>
> on
> FreeBSD 12.1-STABLE #0 r359973M: Thu Apr 16 amd64 1201513 1201513

Ah, yes - r340701 needs to be MFC'd to stable/12 to make this work there.
___
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: ASLR/PIE status in FreeBSD HEAD

[Ed Maste]

On Thu, 23 Apr 2020 at 11:38, Brooks Davis  wrote:
>
> > 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.

Indeed, having a basic smoke test for as much of the base system as
possible is a good initial step. I suspect it won't take very long to
have confidence in turning on options for the base system, but ports
will be a much longer process.

For ports I think the first thing that needs to happen is to have some
infrastructure in ports itself to allow individual ports to indicate
(via elfctl) that they are not compatible with certain options; with
that in place it should be trivial to start marking individual ports.
___
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-20:10.ipfw

[Ed Maste]

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.
___
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-20:10.ipfw

[Ed Maste]

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.
___
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: ASLR/PIE status in FreeBSD HEAD

[Ed Maste]

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-unsubscr...@freebsd.org"

Re: ASLR/PIE status in FreeBSD HEAD

[Ed Maste]

On Fri, 17 Apr 2020 at 09:13, Shawn Webb  wrote:
>
> Quick note: paxtest's algorithms for measuring ASLR was meant to test
> ASLR, not FreeBSD's ASR implementation. Thus, paxtest results for
> FreeBSD's ASR are moot.

paxtest's entropy estimate is superficial, and indeed can produce a
more or less invalid result depending on the distribution of allocated
objects. There are a number of other tools which perform a more
rigorous or comprehensive analysis.

paxtest is useful in providing basic indication of whether various
things are randomized or not.
___
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: ASLR/PIE status in FreeBSD HEAD

[Ed Maste]

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 prevent
> enabling ASLR by default in the kernel and building the base system with
> -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).

> 2. In case the enablement becomes eventually approved, will it be better 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.

> 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 reasonable
> 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 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.

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.
___
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: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

[Ed Maste]

On Sat, 15 Feb 2020 at 05:03, Bjoern A. Zeeb
 wrote:
>
> I am also worried that the change will make a lot of machines
> unprotected upon updating to 13 if there is no big red warning flag
> before the install.

At least having sshd emit a warning is a prerequisite, certainly. I
don't yet know if there's a way via libwrap's API to determine if
rules are in place; there's a bit of investigation needed here still.

> I do understand the burden of maintaining a local patch (we lost the HA
> patches from base this way already).

Indeed. As you pointed out the libwrap patch is very small and easy to
review and reason about. My bigger concern is that libwrap is
essentially abandonware, and it has been dropped by just about
everyone else. As far as I know Debian is still patching libwrap
support into sshd but not anyone else.

It seems starting sshd from inetd via tcpd is a reasonable approach
for folks who want to use it; also, have folks using libwrap looked at
sshd's Match blocks to see if they provide the desired functionality?
___
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: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

[Ed Maste]

On Fri, 14 Feb 2020 at 15:27, Joey Kelly  wrote:
>
> On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote:
> > Upstream OpenSSH-portable removed libwrap support in version 6.7,
> > released in October 2014. We've maintained a patch in our tree to
> > restore it, but it causes friction on each OpenSSH update and may
> > introduce security vulnerabilities not present upstream. It's (past)
> > time to remove it.
>
> So color me ignorant, but how does this affect things like DenyHosts?

It's independent of denyhosts, fail2ban, blacklistd and similar. TCP
wrappers is configured using /etc/hosts.allow and /etc/hosts.deny.
___
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"

Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

[Ed Maste]

Upstream OpenSSH-portable removed libwrap support in version 6.7,
released in October 2014. We've maintained a patch in our tree to
restore it, but it causes friction on each OpenSSH update and may
introduce security vulnerabilities not present upstream. It's (past)
time to remove it.

Although the specific deprecation steps aren't yet fleshed out I'm
sending this as an early notice that I plan to disable libwrap support
from the base system sshd and that FreeBSD 13 will not support it.
We'll probably keep the patch in the tree for some time, to support
MFCs to stable branches; the patch will be removed entirely later on.
___
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-19:10.ufs

[Ed Maste]

On Wed, 3 Jul 2019 at 11:21, Doug Hardie  wrote:
>
> That is going to be a bit tricky to do on a headless server that is remote.  
> None of mine have consoles.  They are all accessed via SSH.  Any ideas how 
> this situation can be handled?

Probably an rc.d script with BEFORE: root that invokes the fsck
command - something along the lines of the following (as yet untested
and missing error checking etc.):

#!/bin/sh
#

# PROVIDE: fsck_ufs
# BEFORE: root
# REQUIRE: fsck
# KEYWORD: nojail

. /etc/rc.subr

name="fsck_ufs"
desc="fsck UFS filesystems for FreeBSD-SA-19:10.ufs"
start_cmd="fsck_ufs_start"
stop_cmd=":"

fsck_ufs_start()
{
fsck -t ufs -f -p -T ufs:-z
}

load_rc_config $name
run_rc_command "$1"
___
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-19:10.ufs

[Ed Maste]

On Wed, 3 Jul 2019 at 06:05, Doug Hardie  wrote:
>
> > Afterwards, reboot the system and run:
> >
> > # fsck -t ufs -f -p -T ufs:-z
> >
> > to clean up your existing filesystems.
>
> After rebooting the system I get:
>
> master# fsck -t ufs -f -p -T ufs:-z
> /dev/ada0p2: NO WRITE ACCESS
> /dev/ada0p2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>
> Is this expected result or is there a problem here?

Thanks for reporting this - it looks like some more detail will need
to be added to the SA. The fsck needs to be run without the filesystem
being mounted read-write, most likely in single user mode.

I brought a test system down to single user mode, remounted / as
read-only, and ran the fsck command as follows:

# shutdown now
...
Enter full pathname of shell or RETURN for /bin/sh:
# mount -u -o ro /
# fsck -t ufs -f -p -T ufs:-z
/dev/ufsid/5bf225f5889c157d: 28576 files, 304757 used, 27570235 free
(899 frags, 3446167 blocks, 0.0% fragmentation)
# exit
___
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: Exploit Lecture: Writing FreeBSD Malware

[Ed Maste]

On 27 April 2018 at 22:39, grarpamp  wrote:
> https://www.youtube.com/watch?v=bT_k06Xg-BE
>
> [Conference talk abstract and bio omitted]

By all means do post interesting and relevant discussion on the lists,
but please don't cross-post to multiple mailing lists with nothing but
cut-and-pasted content from a conference web site, as here.

(I'm not going to respond to the misrepresentation in the talk
abstract itself, but if you're so inclined, do share what you found
interesting about the talk.)
___
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:03.speculative_execution

[Ed Maste]

On 18 March 2018 at 13:54, Jan Demter  wrote:
> Hi Andrea!
>
> Am 16.03.18 um 17:11 schrieb Andrea Venturoli via freebsd-security:
>>
>> On 03/14/18 05:29, FreeBSD Security Advisories wrote:
>>>
>>> # sysctl vm.pmap.pti
>>> vm.pmap.pti: 1
>>
>> Of course I find this enabled on the Intel box and not on the AMD one,
>> but... is PTI in any way affected by a microcode update from Intel?
>
> From what I have read so far, I'm pretty certain it isn't planned or even
> possible to patch this via a microcode update.

That is correct. Meltdown won't ever be fixed with a microcode update
as far as we know, and no microcode update is required for the PTI
mitigation.

There's one small wrinkle: there are some recent lower-end processors
(at least some recent Celerons) which it seems are not susceptible to
Meltdown, and after a microcode update will set a bit to indicate
this. In that case a microcode update will cause FreeBSD to switch
from enabling PTI to disabling it by default -- but that CPU is not
affected by Meltdown, with or without the update.

> IBRS does not seem to be enabled by default:
> https://reviews.freebsd.org/rS328625
> "For existing processors, you need a microcode update which adds IBRS
> CPU features, and to manually enable it by setting the tunable/sysctl
> hw.ibrs_disable to 0."

That is true. Further, we expect the compiler-based retpoline to be
the usual mitigation used for Spectre V2, for CPUs before Skylake.
Development work for this is still ongoing in -CURRENT.
___
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"

Call for Testing: 11.1-RELEASE Meltdown/Spectre mitigation merge

[Ed Maste]

Background
--

A number of issues relating to speculative execution were found last
year and publicly announced January 3rd. A variety of techniques used to
mitigate these issues have been committed to FreeBSD-CURRENT and have
been merged to the stable/11 branch.

The changes will be merged and released as an update to FreeBSD
11.1-RELEASE in the near future, but the candidate patch is now
available for broader testing.

The patch addresses these issues:

CVE-2017-5754 (Meltdown)


This issue relies on a speculative execution of instructions that
attempt to read kernel memory, but fault. Although the architectural
state is as expected (the faulting instruction is not retired), cache or
other microarchitectureal state is changed and may be used to observe
privileged data.

The mitigation is known as Page Table Isolation (PTI). PTI largely
separates kernel and user mode page tables, so that even during
speculative execution most of the kernel's data is unmapped and not
accessible.

A demonstration of the Meltdown vulnerability is available at
https://github.com/dag-erling/meltdown. A positive result is definitive
(that is, the vulnerability exists with certainty). A negative result
indicates either that the CPU is not affected, or that the test is not
capable of demonstrating the issue on the CPU (and may need to be
modified).

CVE-2017-5715 (Spectre V2)
--

Spectre V2 uses branch target injection to speculatively execute kernel
code at an address under an attacker's control.

There are two common mitigations for Spectre V2. This patch includes a
mitigation using Indirect Branch Restricted Speculation, a feature
available via a microcode update from processor manufacturers. The
alternate mitigation, Retpoline, is a feature available in newer
compilers and is available in FreeBSD-CURRENT now. It will be made
available in stable branches in the future.

Patch
-

The patch against 11.1-RELEASE is available at
https://people.freebsd.org/~emaste/patches/amd64_11.1_meltdown.3.patch

A patched kernel will automatically enable PTI on Intel CPUs, and the
status can be checked via the vm.pmap.pti sysctl:

# sysctl vm.pmap.pti
vm.pmap.pti: 1

The default setting can be overridden by setting loader tunable
vm.pmap.pti to 1 or 0 in /boot/loader.conf. This setting takes effect
only at boot.

The patch includes the IBRS mitigation for Spectre V2. To use the
mitigation the system must have an updated microcode; with older
microcode a patched kernel will function without the mitigation.

IBRS can be disabled via the hw.ibrs_disable sysctl (and tunable), and
the status can be checked via the hw.ibrs_active sysctl. IBRS may be
enabled or disabled at runtime. Additional detail on microcode updates
will follow.

Limitations
---

This patch applies only to 11.1-RELEASE. It does not include mitigations
for architectures other than amd64 (x86_64). Work on other branches,
architectures and vulnerabilities is ongoing, and will be available at a
later date.

Testing
---

We are soliciting functionality and performance results from testing
this 11.1-RELEASE patch under a variety of workloads. If you have the
ability to test, please apply the patch and run the system with your
usual workload and follow up with details, either here or directly to
me.

Benchmark data from our testing will soon be shared more widely. In
brief, the PTI mitigation shows on the order of a 30% impact on system
call microbenchmarks, to 1% to 2% for realistic workloads.

This work is supported by the FreeBSD Foundation.
___
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: Re: Response to Meltdown and Spectre

[Ed Maste]

On 27 February 2018 at 15:36, Davide Davini  wrote:
> Hi,
>
> I'd like to know too. Maybe I missed something but as I understand it there
> are only patches on 11-stable now, is that correct?

The change is committed to stable/11, and a patch against 11.1 is
available for testing now. Kostik posted a link to the patch to the
FreeBSD-stable mailing list (see
https://lists.freebsd.org/pipermail/freebsd-stable/2018-February/088451.html).
It will be turned into an update in the near future.

> Is 10 ever going to be patched?

It will, but differences between 10 and 11 mean that more work is
still needed for the backport.
___
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

[Ed Maste]

On 12 January 2018 at 05:36, Zahrir, Abderrahmane
 wrote:
> Hi Gordon,
>
> Is it possible to include me in your distribution list so that I can get 
> notified when the FreeBSD patch is available.

The best way ensure you'll be notified when the changes are available
as a patch or SA for releases is by subscribing to
freebsd-security-notifications, which you can do at
https://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
___
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 "Intel responds to security research findings"

[Ed Maste]

With respect to
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

The FreeBSD Security Team recently learned of the details of these
issues that affect certain CPUs. Details could not be discussed
publicly, but mitigation work is in progress.

Work is ongoing to develop and commit these mitigations to the FreeBSD
repository as soon as possible, with updates for releases to follow.
___
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: The Stack Clash vulnerability

[Ed Maste]

On 3 July 2017 at 12:29, Michelle Sullivan  wrote:
>
> Been watching for it in 10-STABLE... didn't see it go in... did I miss it?

It hasn't yet been merged -- there were a couple of issues with the
initial commit which were fixed shortly after in HEAD. We are now
waiting on the MFC timer for the followup fixes (to provide time to
find any other potential issue).

> Know of any other tests...

I'm not aware of any.
___
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: The Stack Clash vulnerability

[Ed Maste]

On 21 June 2017 at 20:22, Ed Maste <ema...@freebsd.org> wrote:
> These changes are expected to be
> committed to FreeBSD soon, and from there they will be merged to
> stable branches and into updates for supported releases.

The changes have now been merged to HEAD in r320317.
https://svnweb.freebsd.org/changeset/base/320317
___
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: The Stack Clash vulnerability

[Ed Maste]

On 20 June 2017 at 16:22, Ed Maste <ema...@freebsd.org> wrote:
> On 20 June 2017 at 04:13, Vladimir Terziev <vterz...@gvcgroup.com> wrote:
>> Hi,
>>
>> I assume FreeBSD security team is already aware about the Stack Clash 
>> vulnerability, that is stated to affect FreeBSD amongst other Unix-like OS.
>
> Yes, the security team is aware of this. Improvements in stack
> handling are in progress (currently in review).

I would like to provide some additional background on this issue.
First I'd like to thank Qualys for their detailed and thorough
investigation, which is contributing directly to improving FreeBSD.

The FreeBSD security team is aware of and is monitoring this issue,
but is not directly developing in the changes that are in progress.
The issue under discussion is a limitation in a vulnerability
mitigation technique. Changes to improve the way FreeBSD manages stack
growth, and mitigate the issue demonstrated by Qualys'
proof-of-concept code, are in progress by FreeBSD developers
knowledgeable in the VM subsystem. These changes are expected to be
committed to FreeBSD soon, and from there they will be merged to
stable branches and into updates for supported releases.

-Ed
___
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: The Stack Clash vulnerability

[Ed Maste]

On 20 June 2017 at 04:13, Vladimir Terziev  wrote:
> Hi,
>
> I assume FreeBSD security team is already aware about the Stack Clash 
> vulnerability, that is stated to affect FreeBSD amongst other Unix-like OS.

Yes, the security team is aware of this. Improvements in stack
handling are in progress (currently in review).
___
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: /tmp/ecp.* created during kernel build?

[Ed Maste]

On 28 December 2016 at 06:31, Dimitry Andric  wrote:
>
> This looks like a minor bug in elfcopy, when used as objcopy,
> specifically when in combination with the --input-target binary flag:
>
> $ mkdir /tmp/foo
> $ export TMPDIR=/tmp/foo
> $ ls -l /tmp/foo/
> $ /usr/bin/objcopy --input-target binary --output-target elf64-x86-64-freebsd 
>  --binary-architecture i386  cloudabi32_vdso.o bar.o
> $ ls -l /tmp/foo
> total 12
> -rw-r--r--  1 dim  wheel  10198 2016-12-28 12:29:32 ecp.0xbNAi5i
>
> E.g. for some reason this does not clean up the temporary file.

This should be fixed as of r316284 and will be MFCd before 11.1.
___
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: edit others user crontab, security bug

[Ed Maste]

On 3 September 2016 at 02:31, Garrett Wollman  wrote:
>
> I see now that this was fixed by emaste@ yesterday (r305269).  I'm a
> bit disappointed that it was done using MAXLOGNAME, but looking at the
> way it's used in the code, fixing it to use the proper POSIX parameter
> {LOGIN_NAME_MAX} would require significant restructuring, ...

Yep, as I mentioned in the code review for my change I agree cron
warrants a deeper investigation and refactoring, but I wanted to get
the immediate issue fixed as soon as possible.

-Ed
___
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-16:10.linux

[Ed Maste]

On 27 January 2016 at 03:20, FreeBSD Security Advisories
 wrote:
>
> The following command can be used to test if the Linux binary
> compatibility layer is loaded:
>
> # kldstat -m linuxelf

If it is not loaded, kldstat reports:
kldstat: can't find module linuxelf: No such file or directory

If it is loaded, the output will be similar to:
Id  Refs Name
5001 linuxelf
___
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://heartbleed.com/

[Ed Maste]

On 10 April 2014 06:33, Kimmo Paasiala kpaas...@icloud.com wrote:

 Going back to this original report of the vulnerability. Has it been 
 established with certainty that the attacker would first need MITM capability 
 to exploit the vulnerability? I'm asking this because MITM capability is not 
 something that just any attacker can do. Also if this is true then it can be 
 argued that the severity of this vulnerabilty has be greatly exaggerated.

No, the attack does not rely on MITM.  The vulnerability is available
to anyone who can establish a connection.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: FreeBSD's heartbleed response

[Ed Maste]

On 8 April 2014 14:45, Nathan Dorfman n...@rtfm.net wrote:
 Are you sure about that? The only email I saw stated that FreeBSD 8.x
 and 9.x weren't vulnerable because they were using an older OpenSSL,
 from before the vulnerability was introduced.

That is correct.

 FreeBSD 10-STABLE, on the other hand, seems to use the vulnerable
 OpenSSL 1.0.1e, and I didn't immediately see OPENSSL_NO_HEARTBEATS in
 the Makefile there. So I may well be missing something, but it looks
 vulnerable at first glance.

Also correct.

I see that the fixes were committed a few minutes ago:

FreeBSD current: r2642675
http://svnweb.freebsd.org/base?view=revisionrevision=264265

FreeBSD stable/10: r2642676
http://svnweb.freebsd.org/base?view=revisionrevision=264266

FreeBSD 10.0: r264267
http://svnweb.freebsd.org/base?view=revisionrevision=264267
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org

Re: FreeBSD's heartbleed response

[Ed Maste]

On 8 April 2014 14:53, Ed Maste ema...@freebsd.org wrote:
 I see that the fixes were committed a few minutes ago:

Oops, some typos in the revision numbers in my last email (but the
links were fine) -- here are the correct revision numbers:

FreeBSD current: r264265
http://svnweb.freebsd.org/base?view=revisionrevision=264265

FreeBSD stable/10: r264266
http://svnweb.freebsd.org/base?view=revisionrevision=264266

FreeBSD 10.0: r264267
http://svnweb.freebsd.org/base?view=revisionrevision=264267
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org