Changes since OpenSSH 6.9
=========================
This focus of this release is primarily to deprecate weak, legacy
and/or unsafe cryptography.
Security
--------
* sshd(8): OpenSSH 6.8 and 6.9 incorrectly set TTYs to be world-
writable. Local attackers may be able to write arbitrary messages
to logged-in users, including terminal escape sequences.
Reported by Nikolay Edigaryev.
* sshd(8): Portable OpenSSH only: Fixed a privilege separation
weakness related to PAM support. Attackers who could successfully
compromise the pre-authentication process for remote code
execution and who had valid credentials on the host could
impersonate other users. Reported by Moritz Jodeit.
* sshd(8): Portable OpenSSH only: Fixed a use-after-free bug
related to PAM support that was reachable by attackers who could
compromise the pre-authentication process for remote code
execution. Also reported by Moritz Jodeit.
* sshd(8): fix circumvention of MaxAuthTries using keyboard-
interactive authentication. By specifying a long, repeating
keyboard-interactive "devices" string, an attacker could request
the same authentication method be tried thousands of times in
a single pass. The LoginGraceTime timeout in sshd(8) and any
authentication failure delays implemented by the authentication
mechanism itself were still applied. Found by Kingcope.
Potentially-incompatible Changes
--------------------------------
* Support for the legacy SSH version 1 protocol is disabled by
default at compile time.
* Support for the 1024-bit diffie-hellman-group1-sha1 key exchange
is disabled by default at run-time. It may be re-enabled using
the instructions at http://www.openssh.com/legacy.html
* Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
by default at run-time. These may be re-enabled using the
instructions at http://www.openssh.com/legacy.html
* Support for the legacy v00 cert format has been removed.
* The default for the sshd_config(5) PermitRootLogin option has
changed from "yes" to "prohibit-password".
* PermitRootLogin=without-password/prohibit-password now bans all
interactive authentication methods, allowing only public-key,
hostbased and GSSAPI authentication (previously it permitted
keyboard-interactive and password-less authentication if those
were enabled).
New Features
------------
* ssh_config(5): add PubkeyAcceptedKeyTypes option to control which
public key types are available for user authentication.
* sshd_config(5): add HostKeyAlgorithms option to control which
public key types are offered for host authentications.
* ssh(1), sshd(8): extend Ciphers, MACs, KexAlgorithms,
HostKeyAlgorithms, PubkeyAcceptedKeyTypes and HostbasedKeyTypes
options to allow appending to the default set of algorithms
instead of replacing it. Options may now be prefixed with a '+'
to append to the default, e.g. "HostKeyAlgorithms=+ssh-dss".
* sshd_config(5): PermitRootLogin now accepts an argument of
'prohibit-password' as a less-ambiguous synonym of 'without-
password'.
Bugfixes
--------
* ssh(1), sshd(8): add compatability workarounds for Cisco and more
PuTTY versions. bz#2424
* Fix some omissions and errors in the PROTOCOL and PROTOCOL.mux
documentation relating to Unix domain socket forwarding;
bz#2421 bz#2422
* ssh(1): Improve the ssh(1) manual page to include a better
description of Unix domain socket forwarding; bz#2423
* ssh(1), ssh-agent(1): skip uninitialised PKCS#11 slots, fixing
failures to load keys when they are present. bz#2427
* ssh(1), ssh-agent(1): do not ignore PKCS#11 hosted keys that wth
empty CKA_ID; bz#2429
* sshd(8): clarify documentation for UseDNS option; bz#2045
rtrequest has already done it. So we don't need to do it once more.
This fixes regressed behavior of ARP cache expiration which an expired
cache doesn't disappear.
Some chips (e.g. Intel 82599) report SERR and MSI-X interrupt doesn't work.
This problem might not be the driver's bug but our PCI common part or VMs'
bug. See fxp(4), bge(4) and ixgbe(4). All of them has the same workaround
related to prefetchable bit. For the MSI-X table area, it should not have side
effect by prefetching. Until we find a real reason, we ignore the prefetchable
bit.
- Move prototypes of pci_msi[x]_count() from x86/x86/pci_machdep_common to
sys/dev/pci/pcivar.h.
- Move pci_msi[x]_count() from x86/pci/pci_msi_machdep.c to sys/dev/pci/pci.c
(This part changes the native lfs code; the ufs-derived code already
has 64 vs. 32 logic, but as aspects of it are unsafe, and don't
entirely interoperate cleanly with the lfs 64/32 stuff, pass 2 will be
rehashing that.)
other lfs64 on-disk inode numbers; I've been doing that since this is
a new format and we may as well take the opportunity. This does assume
that more than 4 billion files on a single volume becomes desirable;
but for an average file size of 10K all that takes is a 40 TB volume,
and it's not that hard to make one of those these days if you want to
badly enough.
Keep the old BLOCK_INFO as BLOCK_INFO_70, and version the fcntls that
use it.
Note that BLOCK_INFO_70 has 64-bit padding issues so that it's
different on 32-bit and 64-bit machines. This has been fixed. However,
BLOCK_INFO also contains a pointer, so compat32 stuff for 32-on-64 is
still needed and doesn't currently exist.
(instead of the system call entry points)
Avoids duplication.
While touching these, pass the lwp around instead of the proc -- the
latter was there for no other reason than because once upon a time
struct proc was the first argument of all syscalls.
(For that matter, why not just use curlwp instead of passing it around
all over the place? The cost of passing it to every syscall probably
exceeds the cost of loading it from curcpu, even on machines where
it's not just kept in a register all the time.)
Also make note of a cleaner limitation: it seems that when it goes to
coalesce discontiguous files, it mallocs an array with one BLOCK_INFO
for every block in the file. Therefore, with 64-bit LFS, on a 32-bit
platform it will be possible to have files large enough to overflow
the cleaner's address space. Currently these will be skipped and cause
warnings via syslog.
At some point someone should rewrite the logic to coalesce files to
use chunks of some reasonable size, as discontinuity between such
chunks is immaterial and mallocing this much space is silly and
fragile. Also, the kernel only accepts up to 65536 blocks at a time
for bmapv and markv, so processing more than this at once probably
isn't useful and may not even work currently. I don't want to change
this around just now as it's not entirely trivial.
knakahara