On Wed, Jul 22, 2026 at 06:31:36PM -0000, Stuart Henderson wrote: > On 2026-07-22, Raimo Niskanen <[email protected]> wrote: > > On Wed, Jul 22, 2026 at 12:01:23PM -0000, Stuart Henderson wrote: > >> On 2026-07-22, Raimo Niskanen <[email protected]> wrote: > >> > Hello misc@! > >> > > >> > I have some security department in my Company breathing down my neck > >> > because > >> > I run an OpenBSD 7.9 public server that has got OpenSSH 10.3, and their > >> > vulnerability scanning tool Black Kite reports that it is vulnerable to > >> > CVE-2026-59999 (high), CVE-2026-60000 (high), and CVE-2026-6002 > >> > (critical). > >> > > >> > I can find matching descriptions on > >> > https:/openssh.org/releasenotes.html, but those OpenSSH release > >> > notes do not list the CVE numbers: > >> > > >> > CVE-2026-59999 (high), should be: > >> > * sshd(8): DisableForwarding=yes didn't override PermitTunnel=yes > >> > as it was documented to do. Note that PermitTunnel is not enabled > >> > by default. Reported independently by Huzaifa Sidhpurwala of > >> > Redhat and Marko Jevtic. > >> > >> not relevant unless you have PermitTunnel enabled, DisableForwarding > >> enabled, and were expecting the latter to override the former. > >> > >> > CVE-2026-60000 (high), should be: > >> > * sshd(8): avoid a potential pre-authentication denial of service > >> > when GSSAPIAuthentication was enabled (this feature is off by > >> > default). This was not mitigated by MaxAuthTries, but would be > >> > penalised by PerSourcePenalties. This was reported by Manfred Kaiser > >> > of the milCERT AT (Austrian Ministry of Defence). > >> > >> not relevant to OpenBSD's builds which are done without GSSAPI > >> (ypu would need to build yourself with KERBEROS5=yes). > >> > >> > CVE-2026-60002 (critical), should be: > >> > * ssh(1): fix a possible client-side use-after-free if the server > >> > changes its host key during a key reexchange. This was reported by > >> > Zhenpeng (Leo) Lin of Depthfirst. > >> > >> ssh(1) i.e. cloent-sode.only. I think that's this one, > >> > >> Date: 2026/07/06 08:49:58 > >> Author: djm > >> Branch: HEAD > >> Tag: (none) > >> Log: > >> fix ownership and lifetime of several bits of client state that > >> need to persist for the life of the connection, especially the > >> cached hostkey that was being incorrectly freed early on some > >> paths, possibly allowing its use after free. > >> > >> Reported by Zhenpeng (Leo) Lin from depthfirst.com > >> > >> Members: > >> ssh.c:1.633->1.634 > >> sshconnect.c:1.383->1.384 > >> sshconnect.h:1.50->1.51 > >> sshconnect2.c:1.387->1.388 > >> > >> > >> > From what I see none of these fixes has been backported to a syspatch for > >> > OpenBSD 7.9, so I guess they are not deemed severe enough. > >> > > >> > Still, Black Kite dares to call them "high" and "critical", and my > >> > Company's > >> > security department gives me 30 business days for the "high" and 10 for > >> > the > >> > "critical" to remedy by upgrading to OpenSSH 10.4. > >> > > >> > I suppose neither of these will be backported to OpenBSD 7.9, and I dare > >> > say that none of these bugs is one that the server will encounter... > >> > > >> > Does misc@ have any advice on how I should handle my security department, > >> > or possibly on how to "remedy these CVE:s"...? > >> > >> https://www.openssh.org/Fopenbsd.html > > > > That looks promising! > > > > If I follow that HowTo and upgrade to OpenSSH 10.4 by updating the openssh > > source tree and compile - could that conflict with future syspatch:es? > > > > Should I then skip all syspatches that target OpenSSH and continue > > doing manual source code upgrades until the next release? > > > > Just want to be sure... > > syspatches affecting openssh would overwrite, you could either rebuild > (from same or newer unpacked source) or just go with the syspatches if > they fix the problems you care about anyway. > > (I tend to just rebuild openssh from -current cvs on release/stable > systems if I really want the update, it usually works and I find it less > trouble than downloading a separate tar, but you do have to be a bit > more careful with that). >
Great, thanks a lot! Cheers! -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
