Heap buffer overflow in sasliorecv() via padded SASL UNBIND fix introduced state bug in that approach. The copy clamps the size, but it does not advance the buffered offset. On the next receive the server waits for another complete N bytes instead of returning the already-buffered remainder (N - len).
Example: a 562-byte UNBIND with the default 512-byte connection buffer returns 512 bytes, then waits for 562 new bytes rather than the remaining 50. A remote SASL-authenticated client can leave the socket open, so the connection stays stalled until the I/O timeout. Repeated connections could be a resource-exhaustion / DoS vector.
CVE-2026-11610 - incomplete fix may introduce a connection-stall DoS
A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded.
By default, Cockpit supports logging into remote machines via SSH (https://github.com/cockpit-project/cockpit/blob/main/doc/authentication.md#remote-machines). While previous Cockpit versions used the dedicated cockpit-ssh helper (based on libssh), Cockpit since version 326/327 executes "python3 -m cockpit.beiboot", which in turn invokes the OpenSSH "ssh" client to connect to remote machines. The SSH "connect to" feature is available prior to authentication, meaning an attacker with access to the Cockpit webservice can trigger the execution of ssh on the Cockpit host. To be precise: the beiboot process is spawned as part of the authentication flow, but the attacker only needs to supply an arbitrary "Authorization: Basic" header with any credentials (even invalid ones) in a request to "/cockpit+=<hostname>/login" to trigger the ssh invocation. The injected commands execute before SSH authentication completes or fails.
The security issue is that SSH connection parameters are passed down as command-line arguments to ssh without any validation or sanitization. Neither cockpit-ws (C code in cockpitauth.c / cockpitauthorize.c) nor cockpit.beiboot (Python code in beiboot.py) performs any character or format checks on the username or hostname before passing them to the ssh process. In particular, this allows an attacker to invoke ssh on the Cockpit host with an arbitrary username and hostname during the login flow.
The resulting ssh invocation looks like (simplified; additional options like -o NumberOfPasswordPrompts=1 are omitted for clarity):
arg0: ssh arg1: -l arg2: <username> arg3: <hostname> arg4: python3 -ic '# cockpit-bridge'
An attacker has full control over <username> and near-full control over <hostname> (some characters like whitespace and slashes cannot be used because the hostname is extracted from the URL path). Notably, there is no "--" separator between the ssh options and the destination argument, which enables option injection via the hostname field.
This leads to the following two vulnerabilities:
(1) Injection of malicious remote username leading to RCE
SSH allows the use of the remote username as a variable in SSH configuration files via the %r token. A potential SSH configuration could be:
Match exec "/usr/bin/test %r = blockeduser" ProxyCommand /bin/false
With this configuration, ssh executes the command "/usr/bin/test <username> = blockeduser" during connection setup. Since %r is expanded before the command is passed to the shell, an attacker can inject arbitrary shell commands through the username. For example, using the username "x; touch /tmp/flag; #" would cause ssh to execute:
/usr/bin/test x; touch /tmp/flag; # = blockeduser
The command injection occurs before ssh validates the username format. Although ssh ultimately terminates with "remote username containing invalid characters", the injected command ("touch /tmp/flag") has already been executed.
This means if the Cockpit host's sshconfig uses %r in a "Match exec" directive, Cockpit is vulnerable to unauthenticated remote code execution.
I am in parallel in contact with the OpenSSH maintainers to get this problem fixed in OpenSSH as well, though I believe it is also an issue in Cockpit for passing unverified data to ssh.
(2) Injection of malicious hostname leading to RCE
Since the hostname is passed as a positional argument to ssh without a preceding "--" separator (see viassh() in beiboot.py), an attacker can inject SSH options by supplying a hostname that starts with "-". For example, the attacker can pass "-oProxyCommand=<maliciouscommand>" as the hostname via the URL path "/cockpit+=-oProxyCommand=<maliciouscommand>/login".
ProxyCommand is an SSH client option that executes a specified program whenever SSH connects to a remote host. When the original hostname field is consumed as an option instead of a hostname, ssh interprets the next positional argument, which is "python3 -ic '# cockpit-bridge'" (the remote command), as the actual hostname. This means the malicious ProxyCommand is executed as ssh attempts to "connect" to this misinterpreted hostname.
Fortunately, OpenSSH version 9.6 introduced early hostname validation that bans shell metacharacters in command-line hostnames and usernames (https://github.com/openssh/openssh-portable/commit/7ef3787) before establishing an SSH connection. With OpenSSH >= 9.6, the command injection via "-oProxyCommand=<maliciouscommand>" fails because "python3 -ic '# cockpit-bridge'" contains invalid hostname characters (spaces, quotes, etc.), and ssh aborts before executing the ProxyCommand. Nevertheless, on older OpenSSH versions, this check is not available and <maliciouscommand> will be executed by OpenSSH in an attempt to connect to "python3 -ic '# cockpit-bridge'".
The probability that a Cockpit host is vulnerable to this depends on the OpenSSH version installed. Cockpit migrated to the beiboot/OpenSSH path in version 327 (released 2024-10-23), while OpenSSH 9.6 was released on 2023-12-18, which is roughly 10 months earlier. Systems that upgraded Cockpit to >= 327 but did not update OpenSSH to >= 9.6 would be vulnerable to unauthenticated remote code execution via hostname injection.
Potential fix:
1. Add a "--" separator before the destination argument in viassh() (beiboot.py) to prevent option injection via the hostname. This directly mitigates vulnerability (2). 2. Validate both username and hostname using a character allowlist before passing them to ssh. Examples for such validation can be found in OpenSSH's source code: validhostname() and validruser() in ssh.c. This mitigates both vulnerabilities (1) and (2).
Summary:
While the preconditions for these vulnerabilities will likely affect only a subset of Cockpit installations, the impact is critical: unauthenticated remote code execution on the Cockpit host. An attacker with network access to the Cockpit webservice can trigger the exploit with a single crafted HTTP request to the login endpoint. No valid credentials are required, as the injection occurs during the authentication flow before SSH authentication completes.
In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding.
Regarding the Portable OpenSSH 10.0 release:
Due to an error in the release process, the recent Portable OpenSSH release identifies itself as 10.0p2 rather than the intended 10.0p1.
We do not intend to make a new release to fix this mistake. This portable OpenSSH release will henceforth be knows as 10.0p2 and no release numbered 10.0p1 will be made.
Sorry for the confusion, Damien Miller
OpenSSH 10.0 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support.
Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html
Potentially-incompatible changes --------------------------------
This release removes support for the weak DSA signature algorithm, completing the deprecation process that began in 2015 (when DSA was disabled by default) and repeatedly warned over the last 12 months.
scp(1), sftp(1): pass "ControlMaster no" to ssh when invoked by scp & sftp. This disables implicit session creation by these tools when ControlMaster was set to yes/auto by configuration, which some users found surprising. This change will not prevent scp/sftp from using an existing multiplexing session if one had already been created. GHPR557
This release has the version number 10.0 and announces itself as "SSH-2.0-OpenSSH10.0". Software that naively matches versions using patterns like "OpenSSH1" may be confused by this.
sshd(8): this release removes the code responsible for the user authentication phase of the protocol from the per- connection sshd-session binary to a new sshd-auth binary. Splitting this code into a separate binary ensures that the crucial pre-authentication attack surface has an entirely disjoint address space from the code used for the rest of the connection. It also yields a small runtime memory saving as the authentication code will be unloaded after the authentication phase completes. This change should be largely invisible to users, though some log messages may now come from "sshd-auth" instead of "sshd-session". Downstream distributors of OpenSSH will need to package the sshd-auth binary.
sshd(8): this release disables finite field (a.k.a modp) Diffie-Hellman key exchange in sshd by default. Specifically, this removes the "diffie-hellman-group" and "diffie-hellman-group-exchange-" methods from the default KEXAlgorithms list. The client is unchanged and continues to support these methods by default. Finite field Diffie Hellman is slow and computationally expensive for the same security level as Elliptic Curve DH or PQ key agreement while offering no redeeming advantages. ECDH has been specified for the SSH protocol for 15 years and some form of ECDH has been the default key exchange in OpenSSH for the last 14 years.
sshd(8): this release removes the implicit fallback to compiled- in groups for Diffie-Hellman Group Exchange KEX when the moduli file exists but does not contain moduli within the client- requested range. The fallback behaviour remains for the case where the moduli file does not exist at all. This allows administrators more explicit control over which DH groups will be selected, but can lead to connection failures if the moduli file is edited incorrectly. bz#2793
Changes since OpenSSH 9.9 =========================
This release contains a minor security fix as well as a number of feature improvements and bugfixes.
Security ========
sshd(8): fix the DisableForwarding directive, which was failing to disable X11 forwarding and agent forwarding as documented. X11 forwarding is disabled by default in the server and agent forwarding is off by default in the client.
New features ------------
ssh(1): the hybrid post-quantum algorithm mlkem768x25519-sha256 is now used by default for key agreement. This algorithm is considered to be safe against attack by quantum computers, is guaranteed to be no less strong than the popular curve25519-sha256 algorithm, has been standardised by NIST and is considerably faster than the previous default.
ssh(1): prefer AES-GCM to AES-CTR mode when selecting a cipher for the connection. The default cipher preference list is now Chacha20/Poly1305, AES-GCM (128/256) followed by AES-CTR (128/192/256).
ssh(1): add %-token and environment variable expansion to the sshconfig SetEnv directive.
ssh(1): allow %-token and environment variable expansion in the sshconfig User directive, with the exception of %r and %C which would be self-referential. bz#3477
ssh(1), sshd(8): add "Match version" support to sshconfig and sshdconfig. Allows matching on the local version of OpenSSH, e.g. "Match version OpenSSH10.".
ssh(1): add support for "Match sessiontype" to sshconfig. Allows matching on the type of session initially requested, either "shell" for interactive sessions, "exec" for command execution sessions, "subsystem" for subsystem requests, such as sftp, or "none" for transport/forwarding-only sessions.
ssh(1): add support for "Match command ..." support to sshconfig, allowing matching on the remote command as specified on the command-line.
ssh(1): allow 'Match tagged ""' and 'Match command ""' to match empty tag and command values respectively.
sshd(8): allow glob(3) patterns to be used in sshdconfig AuthorizedKeysFile and AuthorizedPrincipalsFile directives. bz2755
sshd(1): support the VersionAddendum in the client, mirroring the option of the same name in the server; bz2745
ssh-agent(1): the agent will now delete all loaded keys when signaled with SIGUSR1. This allows deletion of keys without having access to $SSHAUTHSOCK.
Portable OpenSSH, ssh-agent(1): support systemd-style socket activation in ssh-agent using the LISTENPID/LISTENFDS mechanism. Activated when these environment variables are set, the agent is started with the -d or -D option and no socket path is set. GHPR502
ssh-keygen(1): support FIDO tokens that return no attestation data, e.g. recent WinHello. GHPR542
ssh-agent(1): add a "-Owebsafe-allow=..." option to allow the default FIDO application ID allow-list to be overridden.
Add a work-in-progress tool to verify FIDO attestation blobs that ssh-keygen can optionally write when enrolling FIDO keys. This tool is available under regress/misc/ssh-verify-attestation for experimentation but is not installed by "make install".
ssh-keygen(1): allow "-" as output file for moduli screening. GHPR393
Bugfixes --------
sshd(8): remove assumption that the sshdconfig and any configs it includes can fit in a (possibly enlarged) socket buffer. Previously it was possible to create a sufficiently large configuration that could cause sshd to fail to accept any connection. sshd(8) will now actively manage sending its config to the sshd-session sub-process.
ssh(1): don't start the ObscureKeystrokeTiming mitigations if there has been traffic on a X11 forwarding channel recently. Should fix X11 forwarding performance problems when this setting is enabled. bz3655
ssh(1): prohibit the comma character in hostnames accepted, but allow an underscore as the first character in a hostname.
sftp(1): set high-water when resuming a "put". Prevents bogus "server reordered acks" debug message.
ssh(1), sshd(8): fix regression in openssh-9.8, which would fail to accept "Match criteria=argument" as well as the documented "Match criteria argument" syntax in sshconfig and sshdconfig. bz3739
sftp(1), ssh(1): fix a number possible NULL dereference bugs, including Coverity CIDs 405019 and 477813.
sshd(8): fix PerSourcePenalty incorrectly using "crash" penalty when LoginGraceTime was exceeded. bz3797
sshd(8): fix "Match invalid-user" from incorrectly being activated in initial configuration pass when no other predicates were present on the match line
sshd(8): fix debug logging of user specific delay. GHPR#552
sshd(8): improve debug logging across sub-process boundaries. Previously some log messages were lost early in the sshd-auth and sshd-session processes' life.
ssh(1): require control-escape character sequences passed via the '-e ^x' command-line to be exactly two characters long. Avoids one byte out-of-bounds read if ssh is invoked as "ssh -e^ ..." GHPR368
ssh(1), sshd(8): prevent integer overflow in x11 port handling. These are theoretically possible if the admin misconfigured X11DisplayOffset or the user misconfigures their own $DISPLAY, but don't happen in normal operation. bz#3730
ssh-keygen(1): don't mess up ssh-keygen -l output when the file contains CR characters; GHPR236 bz3385.
sshd(8): add rate limits to logging of connections dropped by PerSourcePenalties. Previously these could be noisy in logs.
ssh(1): fix argument of "Compression" directive in ssh -G config dump, which regressed in openssh-9.8.
sshd(8): fix a corner-case triggered by UpdateHostKeys when sshd refuses to accept the signature returned by an agent holding host keys during the hostkey rotation sub-protocol. This situation could occur in situations where a PKCS#11 smartcard that lacked support for particular signature algorithms was used to store host keys.
ssh-keygen(1): when using RSA keys to sign messages with "ssh-keygen -Y", select the signature algorithm based on the requested hash algorithm ("-Ohashalg=xxx"). This allows using something other than the default of rsa-sha2-512, which may not be supported on all signing backends, e.g. some smartcards only support SHA256.
ssh(1), sshd(8), ssh-keyscan(1): fix ML-KEM768x25519 KEX on big-endian systems.
Many regression and interop test improvements.
Portability -----------
All: add support for AWS-LC (AWS libcrypto). bz3784
sshd(8): add wtmpdb support as a Y2038 safe wtmp replacement.
sshd(8): add support for locking sshd into memory, enabled with the --with-linux-memlock-onfault configure flag.
Add support for building a standalone sk-libfido2 library, enabled by --with-security-key-standalone
ssh(1), sshd(8), ssh-keyscan(1): include builtinpopcount replacement function. for compilers that lack it.
All: Check for and replace le32toh, le64toh, htole64 separately. It appears that at least some versions of endian.h in glibc do not have the latter two. bz#3794
Remove ancient RHL 6.x config in RPM spec.
Checksums: ==========
- SHA1 (openssh-10.0.tar.gz) = 933f4fded0497ef6a588381257276e156a70f9c3 - SHA256 (openssh-10.0.tar.gz) = oaJ+cXLCVoCZAz9W5W1vF7ko4GJW6iq7JmblrPUA34Q=
- SHA1 (openssh-10.0p1.tar.gz) = ac4205e827aea383bf316a33a0e2d5b66b85fcf8 - SHA256 (openssh-10.0p1.tar.gz) = AhoucJoO30JQsSVr1anlAEEakN3avqgw7VnO+Q652Fw=
Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). The PGP key used to sign the releases is available from the mirror sites: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASEKEY.asc
Reporting Bugs: ===============
- Please read https://www.openssh.com/report.html Security bugs should be reported directly to openssh () openssh com
Hi Buherátor, all,
On Thu, Mar 06, 2025 at 10:15:08PM +0100, Buherátor wrote: I also gave this a shot and came up with this query that uses data-flow tracking and also uses StackVariableReachability as suggested by Jordy. I also wrote (much) about the development process to help tweaking the query further: Wow, this is amazing, and your write-up is a gem, thank you so much for working on all this and for sharing it!
Just thinking out loud, but would it somehow be possible to continuously run Jordy's and/or Buherátor's CodeQL queries to prevent the reappearance of such issues?
Maybe someone from CodeQL or GitHub Security Lab could chime in or help with this? Again, just thinking out loud.
Thank you very much! With best regards,
-- the Qualys Security Advisory team
Hi Jordy,
On Fri, Feb 21, 2025 at 01:22:40PM +0100, Jordy Zomer wrote: Hope that's helpful, please reach out if you have any questions :) Woo-hoo, awesome work, thank you very much for sharing it! We are looking into it now (and learning from it).
Thanks again! With best regards,
-- the Qualys Security Advisory team
Hey all,
First of all, cool findings! I've been working on the CodeQL query and have a revised version that I think improves accuracy and might offer some performance gains (though I haven't done rigorous benchmarking). The key change is the use of StackVariableReachability and making sure that there's a path where var is not reassigned before taking a goto ;. Ran it on an older database, found some of the same bugs with no false-positives so far.
This is the revised query. import cpp import semmle.code.cpp.controlflow.StackVariableReachability
// A call that can return 0 class CallReturningOK extends FunctionCall { CallReturningOK() { exists(ReturnStmt ret | this.getTarget() = ret.getEnclosingFunction() and ret.getExpr().getValue().toInt() = 0) } }
class GotoWrongRetvalConfiguration extends StackVariableReachability { GotoWrongRetvalConfiguration() { this = "GotoWrongRetvalConfiguration" }
// Source is an assigment of an "OK" return value to an access of v // To not get FP's we get a false successor override predicate isSource(ControlFlowNode node, StackVariable v) { exists(AssignExpr ae, IfStmt ifst | ae.getRValue() instanceof CallReturningOK and v.getAnAccess() = ae.getLValue() and ifst.getCondition().getAChild() = ae and ifst.getCondition().getAFalseSuccessor() = node) }
// Our intermediate sink is a goto statement, but it should have a successor that's a return of v override predicate isSink(ControlFlowNode node, StackVariable v) { exists(ReturnStmt ret | ret.getExpr() = v.getAnAccess() and node instanceof GotoStmt and node.getASuccessor+() = ret.getExpr()) }
// We don't want v to be reassigned override predicate isBarrier(ControlFlowNode node, StackVariable v) { exists(AssignExpr ae | ae.getLValue() = node and v.getAnAccess() = node) } }
from ControlFlowNode source, ControlFlowNode sink, GotoWrongRetvalConfiguration conf, Variable v, Expr retval where // We want a call that can return 0 to reach a goto that has a ret of v sucessor conf.reaches(source, v, sink) and // We don't want v to be reassigned after the goto not conf.isBarrier(sink.getASuccessor+(), v) // this goes from our intermediate sink to retval and sink.getASuccessor+() = retval // Just making sure that it's returning v and exists(ReturnStmt ret | ret.getExpr() = retval and retval = v.getAnAccess()) select retval.getEnclosingFunction(), source, sink, retval
Hope that's helpful, please reach out if you have any questions :)
Cheers,
Jordy Zomer
Hi Alexander,
On Tue, Jul 23, 2024 at 09:23:10PM +0200, Solar Designer wrote: Hi,
I've finally reviewed the links and re-read the thread. Looks like we're OK to proceed with adding CentOS Project's Hyperscale SIG as a linux-distros member.
Michel, please e-mail me off-list with PGP keys for all of you who need to be subscribed for Hyperscale. I also need to know who will be managing this subscription on your end (informing me of any changes in who's to stay subscribed). Thank you! I'll email once I have collected all the keys. On Wed, Jul 10, 2024 at 06:54:13PM -0500, Michel Lind wrote: All three of us are Fedora developers - but AIUI, we will not and can not use membership here to contribute Fedora patches - until the embargo is over.
For Hyperscale itself we plan to use the head start to have local builds ready to go, and commit and do a public build as soon as the embargo is over; if it needs collaboration we can use private Git repos and E2EE private chats to discuss the fix among ourselves.
This is, to the best of my knowledge, similar to how AlmaLinux handles embargoed security issues - the fix is ready to go but is only made available once the embargo is lifted.
Now - wearing our Fedora hats, we certainly would try and help get this fixed in Fedora once the embargo is over (as we've done before) - and knowing a CVE is going to be made public would certainly help (e.g. trying to make sure one of us is around) - but we won't be participating in the list wearing our Fedora hat, or discuss embargoed issues with people not on the list. This understanding is correct. The membership and embargoed info is only for the specific distro "except with the reporter's explicit approval". This exception means that you may occasionally ask whoever reported the issue to linux-distros for permission to use the information e.g. also for preparing a fix for Fedora even though you're subscribed for Hyperscale. To avoid miscoordination, please keep such requests also CC'ed to the list. Uses of this exception have been very rare so far, and it is expected that you wouldn't use it often, or else it'd make more sense to discuss the additional distro becoming a member. Thanks. Good to know this exception exists, but I'm hoping to prod Fedora to onboard itself as a member anyway. FWIW, Fedora's fix for CVE-2024-6387 was quite timely as-is:
commit dcbca7b947cf82c30d6f477a26efd2f765204fe6 Author: Gordon Messmer <gordon.messmer () gmail com> AuthorDate: Mon Jul 1 20:49:16 2024 -0700 Commit: Gordon Messmer <gordon.messmer () gmail com> CommitDate: Tue Jul 2 00:48:16 2024 -0700
Patch 9.6p1 for CVE-2024-6387
Mon Jul 01 2024 Gordon Messmer <gordon.messmer () gmail com> - 9.6p1-12 - Patch 9.6p1 for CVE-2024-6387
On one hand, this confirms that Fedora cares. On the other, for an issue with a trivial patch, I don't know if Fedora could have done much or anything more to prepare. It was timely .. but there was some scramble in Fedora's security room the morning the embargo was lifted. It turns out the development Rawhide branch was not in a buildable state at that moment - not a big deal, I pointed out at the time that it's more important to fix the stable releases - but with access to the embargo, someone could have fixed the Rawhide build in preparation I suppose. OpenSSH 9.8 released on July 1 also fixed "Logic error in ssh(1) ObscureKeystrokeTiming", which became CVE-2024-39894 by July 3:
https://www.openwall.com/lists/oss-security/2024/07/03/6
Per upstream, this issue affects "9.5 through 9.7 (inclusive)", so I guess Fedora's package based on 9.6p1 is vulnerable. There doesn't appear to be a fix in the package yet. I see this is being tracked in:
https://bugzilla.redhat.com/showbug.cgi?id=2295615
which is assigned to Dmitry Belyavskiy, who is also the maintainer of the OpenSSH package in RHEL and CentOS Stream. RHEL is not affected and the issue is low severity, so will probably take a long while to fix in Fedora via Red Hat. Maybe something the community could do quicker? This is not directly related to possible linux-distros membership; this issue wasn't even on linux-distros. Yeah - the CVE fixes were done by a non-maintainer anyway (Dmitry understandably has his hands full with fixing RHEL and CentOS Stream). This is tangential - but having a well-coordinated security team in Fedora, that participates in this list and in linux-distros, would likely help - e.g. by ensuring that the ACL of key packages like openssh correlates to who often contributes to it, and by making sure issues like these get addressed sooner rather than later.
-- o) Michel Lind ( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
Hi,
I've finally reviewed the links and re-read the thread. Looks like we're OK to proceed with adding CentOS Project's Hyperscale SIG as a linux-distros member.
Michel, please e-mail me off-list with PGP keys for all of you who need to be subscribed for Hyperscale. I also need to know who will be managing this subscription on your end (informing me of any changes in who's to stay subscribed).
On Wed, Jul 10, 2024 at 06:54:13PM -0500, Michel Lind wrote: All three of us are Fedora developers - but AIUI, we will not and can not use membership here to contribute Fedora patches - until the embargo is over.
For Hyperscale itself we plan to use the head start to have local builds ready to go, and commit and do a public build as soon as the embargo is over; if it needs collaboration we can use private Git repos and E2EE private chats to discuss the fix among ourselves.
This is, to the best of my knowledge, similar to how AlmaLinux handles embargoed security issues - the fix is ready to go but is only made available once the embargo is lifted.
Now - wearing our Fedora hats, we certainly would try and help get this fixed in Fedora once the embargo is over (as we've done before) - and knowing a CVE is going to be made public would certainly help (e.g. trying to make sure one of us is around) - but we won't be participating in the list wearing our Fedora hat, or discuss embargoed issues with people not on the list. This understanding is correct. The membership and embargoed info is only for the specific distro "except with the reporter's explicit approval". This exception means that you may occasionally ask whoever reported the issue to linux-distros for permission to use the information e.g. also for preparing a fix for Fedora even though you're subscribed for Hyperscale. To avoid miscoordination, please keep such requests also CC'ed to the list. Uses of this exception have been very rare so far, and it is expected that you wouldn't use it often, or else it'd make more sense to discuss the additional distro becoming a member. I am curious what this could mean for Fedora Asahi Remix [0], as the applicants maintain both distros.
Is there interest in the Asahi SIG applying as well?
I heartily endorse the applicants membership request and appreciate their work. Hooray for ARM \o/ So... if this works for Hyperscale, we could potentially discuss with other Fedora developers about having Fedora itself be represented in linux-distros. Something to bring up at Flock! There's already some discussion of this in the Fedora Security Matrix room w.r.t. last week's OpenSSH CVE. FWIW, Fedora's fix for CVE-2024-6387 was quite timely as-is:
commit dcbca7b947cf82c30d6f477a26efd2f765204fe6 Author: Gordon Messmer <gordon.messmer () gmail com> AuthorDate: Mon Jul 1 20:49:16 2024 -0700 Commit: Gordon Messmer <gordon.messmer () gmail com> CommitDate: Tue Jul 2 00:48:16 2024 -0700
Patch 9.6p1 for CVE-2024-6387
Mon Jul 01 2024 Gordon Messmer <gordon.messmer () gmail com> - 9.6p1-12 - Patch 9.6p1 for CVE-2024-6387
On one hand, this confirms that Fedora cares. On the other, for an issue with a trivial patch, I don't know if Fedora could have done much or anything more to prepare.
OpenSSH 9.8 released on July 1 also fixed "Logic error in ssh(1) ObscureKeystrokeTiming", which became CVE-2024-39894 by July 3:
https://www.openwall.com/lists/oss-security/2024/07/03/6
Per upstream, this issue affects "9.5 through 9.7 (inclusive)", so I guess Fedora's package based on 9.6p1 is vulnerable. There doesn't appear to be a fix in the package yet. I see this is being tracked in:
https://bugzilla.redhat.com/showbug.cgi?id=2295615
which is assigned to Dmitry Belyavskiy, who is also the maintainer of the OpenSSH package in RHEL and CentOS Stream. RHEL is not affected and the issue is low severity, so will probably take a long while to fix in Fedora via Red Hat. Maybe something the community could do quicker? This is not directly related to possible linux-distros membership; this issue wasn't even on linux-distros.
Alexander
On 7/10/24 08:06, Pete Allor wrote: Under CVE rules, Red Hat can only assign a CVE for issues within our scope, which for most CNAs means their software. RH has on occasion, provided a CVE for upstream projects which are not covered by another CNA. That is really about a coordination point between multiple parties. But the scope of Red Hat's CNA explicitly includes all open source projects included in a Red Hat product: https://www.cve.org/PartnerInformation/ListofPartners/partner/redhat
and many projects have been told to contact Red Hat to request CVEs over the years. I know I've requested and received many CVE's from the Red Hat CNA for security advisories issued by the X.Org Foundation - far more than "on occasion".
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Hi,
On 02.07.24 1:47 AM, Dominique Martinet wrote: 2) Logic error in ssh(1) ObscureKeystrokeTiming I couldn't find anything on this one. it seems CVE-2024-39894 got assigned to this now: https://www.cve.org/CVERecord?id=CVE-2024-39894
Regards,
--
Christian Fischer | PGP Key: 0x54F3CE5B76C597AD Greenbone AG, Neumarkt 12, 49074 Osnabrück, Germany https://www.greenbone.net/ Company registry: Amtsgericht Osnabrück, HRB 218768 Board of directors: Dr. Jan-Oliver Wagner (CEO), Elmar Geese Chairman of the Supervisory Board: Lukas Grunwald
USN-6560-1 fixed several vulnerabilities in OpenSSH. This update provides the corresponding update for Ubuntu 16.04 LTS and Ubuntu 18.04 LTS. Original advisory details: Fabian Bäumer, Marcus Brinkmann, Jörg Schwenk discovered that the SSH protocol was vulnerable to a prefix truncation attack. If a remote attacker was able to intercept SSH communications, extension negotiation messages could be truncated, possibly leading to certain algorithms and features being downgraded. This issue is known as the Terrapin attack. This update adds protocol extensions to mitigate this issue. (CVE-2023-48795) It was discovered that OpenSSH incorrectly handled user names or host names with shell metacharacters. An attacker could possibly use this issue to perform OS command injection. This only affected Ubuntu 18.04 LTS. (CVE-2023-51385)
OpenSSH through 9.6, when common types of DRAM are used, might allow row hammer attacks (for authentication bypass) because the integer value of authenticated in mmanswerauthpassword does not resist flips of a single bit. NOTE: this is applicable to a certain threat model of attacker-victim co-location in which the attacker has user privileges.
https://arxiv.org/abs/2309.02545 https://github.com/openssh/openssh-portable/blob/8241b9c0529228b4b86d88b1a6076fb9f97e4a99/auth-passwd.c#L77 https://github.com/openssh/openssh-portable/blob/8241b9c0529228b4b86d88b1a6076fb9f97e4a99/monitor.c#L878
OpenSSH 9.6 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support.
Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html
Changes since OpenSSH 9.5 =========================
This release contains a number of security fixes, some small features and bugfixes.
Security ========
This release contains fixes for a newly-discovered weakness in the SSH transport protocol, a logic error relating to constrained PKCS#11 keys in ssh-agent(1) and countermeasures for programs that invoke ssh(1) with user or hostnames containing invalid characters.
ssh(1), sshd(8): implement protocol extensions to thwart the so-called "Terrapin attack" discovered by Fabian Bäumer, Marcus Brinkmann and Jörg Schwenk. This attack allows a MITM to effect a limited break of the integrity of the early encrypted SSH transport protocol by sending extra messages prior to the commencement of encryption, and deleting an equal number of consecutive messages immediately after encryption starts. A peer SSH client/server would not be able to detect that messages were deleted.
While cryptographically novel, the security impact of this attack is fortunately very limited as it only allows deletion of consecutive messages, and deleting most messages at this stage of the protocol prevents user user authentication from proceeding and results in a stuck connection.
The most serious identified impact is that it lets a MITM to delete the SSH2MSGEXTINFO message sent before authentication starts, allowing the attacker to disable a subset of the keystroke timing obfuscation features introduced in OpenSSH 9.5. There is no other discernable impact to session secrecy or session integrity.
OpenSSH 9.6 addresses this protocol weakness through a new "strict KEX" protocol extension that will be automatically enabled when both the client and server support it. This extension makes two changes to the SSH transport protocol to improve the integrity of the initial key exchange.
Firstly, it requires endpoints to terminate the connection if any unnecessary or unexpected message is received during key exchange (including messages that were previously legal but not strictly required like SSH2MSGDEBUG). This removes most malleability from the early protocol.
Secondly, it resets the Message Authentication Code counter at the conclusion of each key exchange, preventing previously inserted messages from being able to make persistent changes to the sequence number across completion of a key exchange. Either of these changes should be sufficient to thwart the Terrapin Attack.
More details of these changes are in the PROTOCOL file in the OpenSSH source distribition.
ssh-agent(1): when adding PKCS#11-hosted private keys while specifying destination constraints, if the PKCS#11 token returned multiple keys then only the first key had the constraints applied. Use of regular private keys, FIDO tokens and unconstrained keys are unaffected.
ssh(1): if an invalid user or hostname that contained shell metacharacters was passed to ssh(1), and a ProxyCommand, LocalCommand directive or "match exec" predicate referenced the user or hostname via %u, %h or similar expansion token, then an attacker who could supply arbitrary user/hostnames to ssh(1) could potentially perform command injection depending on what quoting was present in the user-supplied sshconfig(5) directive.
This situation could arise in the case of git submodules, where a repository could contain a submodule with shell characters in its user/hostname. Git does not ban shell metacharacters in user or host names when checking out repositories from untrusted sources.
Although we believe it is the user's responsibility to ensure validity of arguments passed to ssh(1), especially across a security boundary such as the git example above, OpenSSH 9.6 now bans most shell metacharacters from user and hostnames supplied via the command-line. This countermeasure is not guaranteed to be effective in all situations, as it is infeasible for ssh(1) to universally filter shell metacharacters potentially relevant to user-supplied commands.
User/hostnames provided via sshconfig(5) are not subject to these restrictions, allowing configurations that use strange names to continue to be used, under the assumption that the user knows what they are doing in their own configuration files.
Potentially incompatible changes --------------------------------
ssh(1), sshd(8): the RFC4254 connection/channels protocol provides a TCP-like window mechanism that limits the amount of data that can be sent without acceptance from the peer. In cases where this limit was exceeded by a non-conforming peer SSH implementation, ssh(1)/sshd(8) previously discarded the extra data. From OpenSSH 9.6, ssh(1)/sshd(8) will now terminate the connection if a peer exceeds the window limit by more than a small grace factor. This change should have no effect of SSH implementations that follow the specification.
New features ------------
ssh(1): add a %j token that expands to the configured ProxyJump hostname (or the empty string if this option is not being used) that can be used in a number of sshconfig(5) keywords. bz3610
ssh(1): add ChannelTimeout support to the client, mirroring the same option in the server and allowing ssh(1) to terminate quiescent channels.
ssh(1), sshd(8), ssh-add(1), ssh-keygen(1): add support for reading ED25519 private keys in PEM PKCS8 format. Previously only the OpenSSH private key format was supported.
ssh(1), sshd(8): introduce a protocol extension to allow renegotiation of acceptable signature algorithms for public key authentication after the server has learned the username being used for authentication. This allows varying sshdconfig(5) PubkeyAcceptedAlgorithms in a "Match user" block.
ssh-add(1), ssh-agent(1): add an agent protocol extension to allow specifying certificates when loading PKCS#11 keys. This allows the use of certificates backed by PKCS#11 private keys in all OpenSSH tools that support ssh-agent(1). Previously only ssh(1) supported this use-case.
Bugfixes --------
ssh(1): when deciding whether to enable the keystroke timing obfuscation, enable it only if a channel with a TTY is active.
ssh(1): switch mainloop from poll(3) to ppoll(3) and mask signals before checking flags set in signal handler. Avoids potential race condition between signaling ssh to exit and polling. bz3531 ssh(1): when connecting to a destination with both the AddressFamily and CanonicalizeHostname directives in use, the AddressFamily directive could be ignored. bz5326
sftp(1): correct handling of the limits () openssh com option when the server returned an unexpected message.
A number of fixes to the PuTTY and Dropbear regress/integration tests.
ssh(1): release GSS OIDs only at end of authentication, avoiding unnecessary init/cleanup cycles. bz2982
sshconfig(5): mention "none" is a valid argument to IdentityFile in the manual. bz3080
scp(1): improved debugging for paths from the server rejected for not matching the client's glob(3) pattern in old SCP/RCP protocol mode.
ssh-agent(1): refuse signing operations on destination-constrained keys if a previous session-bind operation has failed. This may prevent a fail-open situation in future if a user uses a mismatched ssh(1) client and ssh-agent(1) where the client supports a key type that the agent does not support.
Portability -----------
Better identify unsupported and unstable compiler flags, such as -fzero-call-used-regs which has been unstable across a several clang releases.
A number of fixes to regression test reliability and log collection.
Update the OpenSSL dependency in the RPM specification.
sshd(8): for OpenSolaris systems that support privilege limitation via the getpflags() interface, prefer using the newer PRIVXPOLICY to PRIVLIMIT. bz2833
Checksums: ==========
- SHA1 (openssh-9.6.tar.gz) = a6d4cb69811e879e2f158c2e597fd9f444b26506 - SHA256 (openssh-9.6.tar.gz) = nejPUhSnG1R1sOmIBi/t+HMNvsRqfN/DJgjwIU2tvqg=
- SHA1 (openssh-9.6p1.tar.gz) = de300d09ec79fdbf37de4e6672cce4161439f2c3 - SHA256 (openssh-9.6p1.tar.gz) = kQIRwHJVqMWtZUORtA7lmABxDdgRndU2LeCThap6d3w=
Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). The PGP key used to sign the releases is available from the mirror sites: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASEKEY.asc
Reporting Bugs: ===============
- Please read https://www.openssh.com/report.html Security bugs should be reported directly to openssh () openssh com
On Fri, Jul 21, 2023 at 11:04:49AM +1000, Matthew Fernandez wrote: On 7/20/23 23:41, Sevan Janiyan wrote: On 20/07/2023 14:24, Demi Marie Obenour wrote: Should there be a system-wide configuration file containing a list of known-good PKCS#11 libraries? ssh-agent having to guess if something is a PKCS#11 library is less than awesome. There's a compile time setting for paths from which you are able to load libraries from. I don’t think this helps much though, right? The Qualys research that motivated this found an exploit chain using only libs present in /usr/lib in a default Ubuntu install. If you want to lock down loading to a specific non-/usr/lib path that you have control over, this suggests you know and are in control of the PKCS#11 providers you’re going to support. In which case, why not avoid dynamic loading to begin with? I guess the allowlist and new defaults are the answer to this conundrum though. IMO the root cause of this problem is that PKCS#11 libraries are installed in /usr/lib, rather than in /usr/lib/pkcs11 or another subdirectory. There should be an automated way to check if a library is a PKCS#11 library without having to load it. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
The PKCS#11 feature in ssh-agent in OpenSSH before 9.3p2 has an insufficiently trustworthy search path, leading to remote code execution if an agent is forwarded to an attacker-controlled system. (Code in /usr/lib is not necessarily safe for loading into ssh-agent.) NOTE: this issue exists because of an incomplete fix for CVE-2016-10009.
OpenSSH 9.3p2 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support.
Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html
Changes since OpenSSH 9.3 =========================
This release fixes a security bug.
Security ========
Fix CVE-2023-38408 - a condition where specific libaries loaded via ssh-agent(1)'s PKCS#11 support could be abused to achieve remote code execution via a forwarded agent socket if the following conditions are met:
Exploitation requires the presence of specific libraries on  the victim system. Remote exploitation requires that the agent was forwarded  to an attacker-controlled system.
Exploitation can also be prevented by starting ssh-agent(1) with an empty PKCS#11/FIDO allowlist (ssh-agent -P '') or by configuring an allowlist that contains only specific provider libraries.
This vulnerability was discovered and demonstrated to be exploitable by the Qualys Security Advisory team. In addition to removing the main precondition for exploitation, this release removes the ability for remote ssh-agent(1) clients to load PKCS#11 modules by default (see below).
Potentially-incompatible changes --------------------------------
ssh-agent(8): the agent will now refuse requests to load PKCS#11 modules issued by remote clients by default. A flag has been added to restore the previous behaviour "-Oallow-remote-pkcs11".
Note that ssh-agent(8) depends on the SSH client to identify requests that are remote. The OpenSSH >=8.9 ssh(1) client does this, but forwarding access to an agent socket using other tools may circumvent this restriction.
Checksums: ==========
- SHA1 (openssh-9.3p2.tar.gz) = 219cf700c317f400bb20b001c0406056f7188ea4 - SHA256 (openssh-9.3p2.tar.gz) = IA6+FH9ss/EB/QzfngJEKvfdyimN/9n0VoeOfMrGdug=
Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). The PGP key used to sign the releases is available from the mirror sites: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASEKEY.asc
Reporting Bugs: ===============
- Please read https://www.openssh.com/report.html Security bugs should be reported directly to openssh () openssh com
ssh-agent in OpenSSH before 8.5 has a double free that may be relevant in a few less-common scenarios, such as unconstrained agent-socket access on a legacy operating system, or the forwarding of an agent to an attacker-controlled host.
scp in OpenSSH through 8.3p1 allows command injection in scp.c remote function, as demonstrated by backtick characters in the destination argument. NOTE: the vendor reportedly has stated that they intentionally omit validation of "anomalous argument transfers" because that could "stand a great chance of breaking existing workflows."
Reference: https://www.openssh.com/security.html
DISPUTED scp in OpenSSH through 8.3p1 allows command injection in the scp.c toremote function, as demonstrated by backtick characters in the destination argument. NOTE: the vendor reportedly has stated that they intentionally omit validation of "anomalous argument transfers" because that could "stand a great chance of breaking existing workflows."
DISPUTED The scp client in OpenSSH 8.2 incorrectly sends duplicate responses to the server upon a utimes system call failure, which allows a malicious unprivileged user on the remote server to overwrite arbitrary files in the client's download directory by creating a crafted subdirectory anywhere on the remote server. The victim must use the command scp -rp to download a file hierarchy containing, anywhere inside, this crafted subdirectory. NOTE: the vendor points out that "this attack can achieve no more than a hostile peer is already able to achieve within the scp protocol" and "utimes does not fail under normal circumstances."
OpenSSH 7.7 through 7.9 and 8.x before 8.1, when compiled with an experimental key type, has a pre-authentication integer overflow if a client or server is configured to use a crafted XMSS key. This leads to memory corruption and local code execution because of an error in the XMSS key parsing algorithm. NOTE: the XMSS implementation is considered experimental in all released OpenSSH versions, and there is no supported way to enable it when building portable OpenSSH.
USN-3885-1 fixed vulnerabilities in OpenSSH. It was discovered that the fix for CVE-2019-6111 turned out to be incomplete. This update fixes the problem. Original advisory details: Harry Sintonen discovered multiple issues in the OpenSSH scp utility. If a user or automated system were tricked into connecting to an untrusted server, a remote attacker could possibly use these issues to write to arbitrary files, change directory permissions, and spoof client output.
An issue was discovered in gsi-openssh-server 7.9p1 on Fedora 29. If PermitPAMUserChange is set to yes in the /etc/gsissh/sshdconfig file, logins succeed with a valid username and an incorrect password, even though a failure entry is recorded in the /var/log/messages file.
OpenSSH has a vulnerability in the scp client utility. Due to missing character encoding in the progress display, the object name can be used to manipulate the client output, for example to employ ANSI codes to hide additional files being transferred.
External Reference:
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt
Proposed Patch:
https://sintonen.fi/advisories/scp-name-validator.patch
In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to bypass intended access restrictions via the filename of . or an empty filename.
Upstream Patch:
https://github.com/openssh/openssh-portable/commit/6010c030 https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/scp.c.diff?r1=1.197&r2=1.198&f=h
OpenSSH through 7.7 is prone to a user enumeration vulnerability due to not delaying bailout for an invalid authenticating user until after the packet containing the request has been fully parsed, related to auth2-gss.c, auth2-hostbased.c, and auth2-pubkey.c.
Upstream Patch:
https://github.com/openbsd/src/commit/779974d35b4859c07bc3cb8a12c74b43b0a7d1e0
Reference:
http://www.openwall.com/lists/oss-security/2018/08/15/5