From ${URL} : Security -------- * ssh-agent(1): Will now refuse to load PKCS#11 modules from paths outside a trusted whitelist (run-time configurable). Requests to load modules could be passed via agent forwarding and an attacker could attempt to load a hostile PKCS#11 module across the forwarded agent channel: PKCS#11 modules are shared libraries, so this would result in code execution on the system running the ssh-agent if the attacker has control of the forwarded agent-socket (on the host running the sshd server) and the ability to write to the filesystem of the host running ssh-agent (usually the host running the ssh client). Reported by Jann Horn of Project Zero. * sshd(8): When privilege separation is disabled, forwarded Unix- domain sockets would be created by sshd(8) with the privileges of 'root' instead of the authenticated user. This release refuses Unix-domain socket forwarding when privilege separation is disabled (Privilege separation has been enabled by default for 14 years). Reported by Jann Horn of Project Zero. * sshd(8): Avoid theoretical leak of host private key material to privilege-separated child processes via realloc() when reading keys. No such leak was observed in practice for normal-sized keys, nor does a leak to the child processes directly expose key material to unprivileged users. Reported by Jann Horn of Project Zero. * sshd(8): The shared memory manager used by pre-authentication compression support had a bounds checks that could be elided by some optimising compilers. Additionally, this memory manager was incorrectly accessible when pre-authentication compression was disabled. This could potentially allow attacks against the privileged monitor process from the sandboxed privilege-separation process (a compromise of the latter would be required first). This release removes support for pre-authentication compression from sshd(8). Reported by Guido Vranken using the Stack unstable optimisation identification tool (http://css.csail.mit.edu/stack/) * sshd(8): Fix denial-of-service condition where an attacker who sends multiple KEXINIT messages may consume up to 128MB per connection. Reported by Shi Lei of Gear Team, Qihoo 360. * sshd(8): Validate address ranges for AllowUser and DenyUsers directives at configuration load time and refuse to accept invalid ones. It was previously possible to specify invalid CIDR address ranges (e.g. user@....1.2.3/55) and these would always match, possibly resulting in granting access where it was not intended. Reported by Laurence Parry @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
I am not sure if we need this security bug. The only real security problem is CVE-2016-8858 which was already handled in bug 597360. At least no A3.
i'm working on the hpn update. we'll see if x509 comes out soon (it usually does) before doing the bump.
(In reply to SpanKY from comment #2) > i'm working on the hpn update. we'll see if x509 comes out soon (it usually > does) before doing the bump. http://dev.gentoo.org/~polynomial-c/openssh-7.4p1-hpnssh14v12.tar.xz
(In reply to Lars Wendler (Polynomial-C) from comment #3) > (In reply to SpanKY from comment #2) > > i'm working on the hpn update. we'll see if x509 comes out soon (it usually > > does) before doing the bump. > > http://dev.gentoo.org/~polynomial-c/openssh-7.4p1-hpnssh14v12.tar.xz Damn, screw it. I broke something :-(
(In reply to Lars Wendler (Polynomial-C) from comment #4) don't worry about it ... i need to do the rebase anyways to push to the upstream hpn git repo
i've pushed out my 7.4p1 updates, sans hpn. hitting interop test failures again like we were with 7.2p1. i don't think we ever tracked down those issues, they just seemed to go away with 7.3p1.
Mike, It doesn't build with USE=X509. Without it, it does. Here's the error: In file included from ssh.c:123:0: ssh.c: In function ‘main’: version.h:5:46: error: expected ‘)’ before ‘SSH_X509’ #define SSH_RELEASE SSH_VERSION SSH_PORTABLE SSH_X509 ^ ssh.c:807:8: note: in expansion of macro ‘SSH_RELEASE’ SSH_RELEASE, ^~~~~~~~~~~ ssh.c:806:26: warning: format ‘%s’ expects a matching ‘char *’ argument [-Wformat=] fprintf(stderr, "%s, %s\n", ^ In file included from ssh.c:123:0: version.h:5:46: error: expected ‘)’ before ‘SSH_X509’ #define SSH_RELEASE SSH_VERSION SSH_PORTABLE SSH_X509 ^ ssh.c:1064:19: note: in expansion of macro ‘SSH_RELEASE’ logit("%s, %s", SSH_RELEASE, ^~~~~~~~~~~ ssh.c:1064:15: warning: format ‘%s’ expects a matching ‘char *’ argument [-Wformat=] logit("%s, %s", SSH_RELEASE, ^ I'm using gcc-6.2 in case it matters. Thanks, Calchan.
(In reply to Denis Dupeyron from comment #7) > > It doesn't build with USE=X509. Without it, it does. > See bug #603610
Mike, for some reason unknown to me, in version.h putting SSH_X509 on it own #define line works.
(In reply to Denis Dupeyron from comment #7) should be fixed by: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c4f141d88c8d955ecbe86554ef21892b0aec762a
@ Maintainer(s): While most issues form 7.4 changelog should be already addressed in our 7.3 versions please tell us if we are ready to start stabilization of =net-misc/openssh-7.4_p1 or how you would like to proceed.
7.5p1 is in the tree now w/hpn patchset since it is passing tests for me. i guess give it a few weeks and we can stabilize that. haven't heard of any other 7.4p1 regressions.
Note CVE's have only been filed up to 7.4.1_p1 (7.5 and 7.5.1 CVE's to be added at a later time).
7.5p1-r1 is now in the tree with the updated X509 patch, it passes tests with both just X509 and X509+hpn
Maintainer(s), please advise if you are ready for stabilization or call for stabilization yourself.
Checked on bugs .. does not look like any. Are we ready for it now?
We have been holding on to this vulnerability for a few months? are you ready for stabilization?
Arches please test and mark stable =net-misc/openssh-7.5_p1-r1 with target KEYWORDS: alpha amd64 arm ~arm64 hppa ia64 ~m68k ~mips ppc ppc64 ~s390 ~sh sparc x86 ~ppc-aix ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris
x86 stable
amd64 stable
sparc stable
ia64 stable
ppc64 stable
arm stable
Stable on alpha.
ppc stable
Arches, please finish stabilizing hppa Gentoo Security Padawan ChrisADR
hppa stable
(In reply to Thomas Deutschmann from comment #1) > I am not sure if we need this security bug. The only real security problem > is CVE-2016-8858 which was already handled in bug 597360. At least no A3. Agreed. Tree is clean. GLSA Vote: No
