Page MenuHomeFreeBSD

sshd: update the libwrap patch to drop connections early
Needs ReviewPublic

Authored by glebius on Wed, Nov 17, 9:15 PM.

Details

Reviewers
emaste
des
Group Reviewers
secteam
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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 42849
Build 39737: arc lint + arc unit

Event Timeline

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

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.

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.

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.

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.

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

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.