[MacPorts] #59497: openssh @8.1p1: sshd only works in debug mode
MacPorts
noreply at macports.org
Fri Nov 8 22:32:35 UTC 2019
#59497: openssh @8.1p1: sshd only works in debug mode
-------------------------+--------------------------------------
Reporter: davidfavor | Owner: Mihai Moldovan <ionic@…>
Type: defect | Status: closed
Priority: Normal | Milestone:
Component: ports | Version: 2.6.2
Resolution: fixed | Keywords:
Port: openssh |
-------------------------+--------------------------------------
Changes (by Mihai Moldovan <ionic@…>):
* owner: (none) => Mihai Moldovan <ionic@…>
* status: reopened => closed
* resolution: => fixed
Comment:
In [changeset:"4adcdc8b8e606bb55f83b33a2c60362292a99066/macports-ports"
4adcdc8b8e606bb55f83b33a2c60362292a99066/macports-ports] (master):
{{{
#!ConfigurableCommitTicketReference repository="macports-ports"
revision="4adcdc8b8e606bb55f83b33a2c60362292a99066"
net/openssh: fix sshd failure in non-debug mode. Revbump.
This commit message is essentially just a copy of the source code comment.
ssh_sandbox_child() has the side-effect of disabling opening new files.
This is a security precaution to prevent the child process from leaking
data or opening new sockets, but clashes with newer OpenSSL
implementations.
Generally, OpenSSL wants to read new entropy from the system for each
reseeding operation (and, by extension, through any operation that might
trigger an internal reseeding, like requesting random bytes).
The current OpenSSL port only enables the default set of system entropy
- which means reading in data from crypto devices like /dev/{,u,s}random
and /dev/hwrng.
To speed things up, OpenSSL tries to open file descriptors to the listed
devices and caches the result, i.e., the open file descriptor. Those are
normally kept open UNLESS a reading error occurred OR no random bytes
were returned.
In a quite scary move, OpenSSL versions prior to 1.1.1 didn't fail when
getting system entropy wasn't successful and also added some
"pseudo-random" data like the PID, user id and current time to the
entropy pool, which was often enough to seed the PRNG.
More recent versions have a rewritten PRNG/DRBG core and, crucially,
stricter rules when it comes to acquiring system entropy - this is now
strictly required and no other data is mixed into the pool.
OpenSSH generally tries (or intends) to leave crypto devices (which
should one of the earliest open devices) alone and not close their FD on
re-exec, but that doesn't seem to work. Although OpenSSL is initialized
very early in the main() call chain, which SHOULD lead to open file
descriptors to crypto devices, on a typical OS X/macOS system,
/dev/urandom is opened as FD 6, which is above any FD that would be
preserved after a re-exec operation.
This leads to the child process having no open file descriptors to
/dev/urandom, activating the sandbox, setting the number of open files
to zero and subsequently effectively breaking OpenSSL 1.1.1+.
We'll work around that by reseeding the PRNGs before enabling the
sandbox, which has the side-effect of opening a file descriptor to
/dev/urandom and keeping it open.
There is a slight catch: errors in reading from the FD or a read count
of zero (i.e., the device not returning any data) will lead to the FD
being closed again without a way to be re-opened.
We can take this risk, as this should realistically not happen. Even if
it does, that only means that the child process will fail to read random
data and hence terminate with an error - showing the same symptoms the
workaround is intended to fix, but nothing worse.
Fixes: https://trac.macports.org/ticket/59497
}}}
--
Ticket URL: <https://trac.macports.org/ticket/59497#comment:17>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list