Have it call native getentropy and fall back as required. Should fix
issues of platforms where libc has getentropy but it is not implemented
in the kernel. Based on github PR#354 from simsergey.
This brings us up to current, including djm's random-reseeding change,
as prompted by logan at cyberstorm.mu in bz#3467. It brings the
platform-specific hooks from LibreSSL Portable, simplified to match our
use case. ok djm@.
Putting this after the copyright statement (which doesn't change)
instead of before the version identifier (which does) prevents merge
conflicts when resyncing changes.
Since arc4random seeds from getentropy, and we use OpenSSL for that
if enabled, there's the possibility that if we build on a system that
does not have getentropy then run on a system that does have it, then
OpenSSL could end up calling our getentropy and getting stuck in a loop.
Pointed out by deraadt@, ok djm@
Factor out the arc4random seeding into its own file and change the
interface to match getentropy. Use native getentropy if available.
This will make it easier to resync OpenBSD changes to arc4random.
Prompted by bz#3467, ok djm@.
We have some compatibility hacks that were added to support OpenSSL
versions that do not support AES CTR mode. Since that time, however,
the minimum OpenSSL version that we support has moved to 1.0.1 which
*does* have CTR, so this is no longer needed. ok djm@
We have some compatibility hacks that were added to support OpenSSL
versions that do not support AES GCM mode. Since that time, however,
the minimum OpenSSL version that we support has moved to 1.0.1 which
*does* have GCM, so this is no longer needed. ok djm@
If getcwd() is supplied a buffer size of exactly 1 and a path of "/", it
could result in a nul byte being written out of array bounds. POSIX says
it should return ERANGE if the path will not fit in the available buffer
(with terminating nul). 1 byte cannot fit any possible path with its nul,
so immediately return ERANGE in that case.
OpenSSH never uses getcwd() with this buffer size, and all current
(and even quite old) platforms that we are currently known to work
on have a native getcwd() so this code is not used on those anyway.
Reported by Qualys, ok djm@
If the underlying system's select() returns bits that were not in the
request set, our ppoll() implementation can return revents for events
not requested, which can apparently cause a hang. Only return revents
for activity in the requested event set. bz#3416, analysis and fix by
yaroslav.kuzmin at vmssoftware com, ok djm@
On some (most? all?) SysV based systems with STREAMS based ptys,
sshd could acquire a controlling terminal during pty setup when
it pushed the "ptem" module, due to what is probably a bug in
the STREAMS driver that's old enough to vote. Because it was the
privileged sshd's controlling terminal, it was not available for
the user's session, which ended up without one. This is known to
affect at least Solaris <=10, derivatives such as OpenIndiana and
several other SysV systems. See bz#245 for the backstory.
In the we past worked around that by not calling setsid in the
privileged sshd child, which meant it was not a session or process
group leader. This solved controlling terminal problem because sshd
was not eligble to acquire one, but had other side effects such as
not cleaning up helper subprocesses in the SIGALRM handler since it
was not PG leader. Recent cleanups in the signal handler uncovered
this, resulting in the LoginGraceTime timer not cleaning up privsep
unprivileged processes.
This change moves the workaround into the STREAMS pty allocation code,
by allocating a sacrificial pty to act as sshd's controlling terminal
before allocating user ptys, so those are still available for users'
sessions.
On the down side:
- this will waste a pty per ssh connection on affected platforms.
On the up side:
- it makes the process group behaviour consistent between platforms.
- it puts the workaround nearest the code that actually causes the
problem and competely out of the mainline code.
- the workaround is only activated if you use the STREAMS code. If,
say, Solaris 11 has the bug but also a working openpty() it doesn't
matter that we defined SSHD_ACQUIRES_CTTY.
- the workaround is only activated when the fist pty is allocated,
ie in the post-auth privsep monitor. This means there's no risk
of fd leaks to the unprivileged processes, and there's no effect on
sessions that do not allocate a pty.
Based on analysis and work by djm@, ok djm@
The Cygwin-specific pattern match code has a bug. It checks
the size_t value returned by mbstowcs for being < 0. The right
thing to do is to check against (size_t) -1. Fix that.
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Correct handling of select(2) exceptfds. These should only be consulted
for POLLPRI flagged pfds and not unconditionally converted to POLLERR.
with and ok dtucker@
Darwin's poll(2) implementation is broken. For character-special
devices like /dev/null, it returns POLLNVAL when polled with
POLLIN.
Apparently this is Apple bug 3710161, which is AFAIK not public,
but a websearch will find other OSS projects rediscovering it
periodically since it was first identified in 2005 (!!)
The main change is that Niels Provos kindly agreed to rescind the
BSD license advertising clause, shifting them to the 3-term BSD
license.
This was the last thing in OpenSSH that used the advertising clause.
glibc's closefrom implementation does not work in a chroot when the kernel
does not have close_range. It tries to read from /proc/self/fd and when
that fails dies with an assertion of sorts. Instead, call close_range
ourselves from our compat code and fall back if that fails. bz#3349,
with william.wilson at canonical.com and fweimer at redhat.com.
Darren Tucker
Damien Miller
Sam James
Tobias Heider
Corinna Vinschen