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

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.

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? Or is 
there an in-application way to block dictionary attacks? I can't go back to 
having my servers pounded on day and night (and yes, I listed on an 
alternative port).

-- 
Joey Kelly
Minister of the Gospel and Linux Consultant
http://joeykelly.net
504-239-6550

On 14 Feb 2020, at 18:18, Ed Maste wrote:

Hi Ed,
> 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.
I?ll be sad to run inetd again on systems so that I can run a wrapped 
sshd.
Like others I feel that adding firewalls to a machine simply to filter 
sshd is not an option and whatever else openssh itself has offered in 
the past never sufficed.

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.


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

Given the port already does maintain the patch I am wondering what 
?security guarantees? we provide for the port compared to the base 
system (ignoring possible security updates) or why the patch cannot be 
included in base?  Compared to the HA patch, this one seems to be 
sillily small..


/bz

> On 14 Feb 2020, at 19:18, Ed Maste <emaste at freebsd.org> 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.
There?s no way to fight it? I know it?s an old program (first time I used it was
back in 1992 or so!)
but it?s really convenient and easy to use. 





Borja.

On 2/14/2020 10:18 AM, 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.
> 
> 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.
FYI if you need this feature the port still has it and is at 8.2 now.


-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20200323/cdc1e79b/attachment.sig>