sshd: update the libwrap patch to drop connections early

[glebius]

Summary

OpenSSH has dropped libwrap support in OpenSSH 6.7p in 2014
(f2719b7c in github.com/openssh/openssh-portable) and we
maintain the patch ourselves since 2016 (a0ee8cc636cd).

Over the years, the libwrap support has deteriotated and probably
that was reason for removal upstream. Original idea of libwrap was
to drop illegitimate connection as soon as possible, but over the
years the code was pushed further down and down and ended in the
forked client connection handler.

The negative effects of late dropping is increasing attack surface
for hosts that are to be dropped anyway. Apart from hypothetical
future vulnerabilities in connection handling, today a malicious
host listed in /etc/hosts.allow still can trigger sshd to enter
connection throttling mode, which is enabled by default (see
MaxStartups in sshd_config(5)), effectively casting DoS attack.
Note that on OpenBSD this attack isn't possible, since they enable
MaxStartups together with UseBlacklist.

A only negative effect from early drop, that I can imagine, is that
now main listener parses file in /etc, and if our root filesystems
goes bad, it would get stuck. But unlikely you'd be able to login
in that case anyway.

[emaste]

Does this then expose the main process to potential vulnerabilities in libwrap?

[glebius]

In D33044#746788, @emaste wrote:

Does this then expose the main process to potential vulnerabilities in libwrap?

That's true of course. But I would estimate that as a lesser evil. So, for a host that is not blocked by hosts.allow, the patch would add 3 library calls into libwrap as new attack surface. And that is addition to the main process only, same library calls were exposed pre-patch, but for a child process. But the patch will reduce attack surface both in the main process and in the child for a substantial amount of lines and other library calls.

[glebius]

Also, libwrap is quite a seasoned open source software, that doesn't see any updates. Chances for a new vulnerability I would estimate as very low.

[lattera-gmail.com]

In D33044#746877, @glebius wrote:

Also, libwrap is quite a seasoned open source software, that doesn't see any updates. Chances for a new vulnerability I would estimate as very low.

We thought the same about OpenSSL, too.

[bz]

In D33044#746879, @lattera-gmail.com wrote:

In D33044#746877, @glebius wrote:

Also, libwrap is quite a seasoned open source software, that doesn't see any updates. Chances for a new vulnerability I would estimate as very low.

We thought the same about OpenSSL, too.

That's a totally different can of worms comapred to libwrap.

[bz]

Without revieweing the code, I am in favour of the conceptual idea.

[glebius]

In D33044#746879, @lattera-gmail.com wrote:

We thought the same about OpenSSL, too.

Not really. OpenSSL was and is always evolving code. libwrap is seeing only compiler fixes in the last 20 years. We should actually move it out of contrib and cleanse, but that's a different story.

[glebius]

I expected some response from the secteam. If no response until Monday, I'm going to commit next week.

[emaste]

Over the years, the libwrap support has deteriotated and probably
that was reason for removal upstream.

It was in fact an intentional choice; from the openssh-unix-dev mailing list:

---------- Forwarded message ---------
From: Damien Miller <[e-mail]>
Date: Wed, 23 Jun 2021 at 23:14
Subject: Re: Bringing back tcp wrappers

…
No - we have no intention of bringing libwrap back. It's a horrible
interface that makes a lot of assumptions about the caller (e.g. it
uses longjmp(3) internally). It shambled out of the 1990s - a time when
hosts and applications lacked similar controls of their own.

It has been comprehensively superseded by better controls both inside
sshd (e.g. the match directive in sshd_config) and included in modern
operating systems (e.g. built-in packet filtering, libpam).

If you really really want libwrap, then you can still get it by
running sshd under a supporting inetd or wrapper program. Alternately,
I think there's a PAM module that implements it.

[glebius]

I promised to already have committed the change, but I didn't. Given holidays quiet period I'd probably abstain from committing it. I plan to commit it on December 26, one week from now.

[emaste]

We would be much better served by improving openssh's built-in controls, and I expect that we will in fact retire librawp in the future.

[glebius]

In D33044#758472, @emaste wrote:

We would be much better served by improving openssh's built-in controls, and I expect that we will in fact retire librawp in the future.

Would be great to retire it once sshd provides same functionality. Right now without a firewall libwrap is the only way to protect yourself from being locked out by MaxStartups.

[bz]

In D33044#758472, @emaste wrote:

We would be much better served by improving openssh's built-in controls, and I expect that we will in fact retire librawp in the future.

Retiring libwrap functionality sounds very wrong to me. It'll force so many more people to run a firewall and shoot themselves in the foot regularly as it goes with firewall configs just to shield few services which otherwise are happy and have been happy with libwrap for 2 decades+. Never change a running system (unless there is a very good reason).

Edit: I assumed you want to retire libwrap from FreeBSD but it comes to me now that you may mean sshd. I wonder what the reasons were and I hope it wasn't NIH.

[emaste]

Would be great to retire it once sshd provides same functionality.

Yes, having equivalent functionality is a prerequisite.

[glebius]

Bug fix: always reset RQ_CLIENT_NAME, RQ_CLIENT_ADDR to empty strings.