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.

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

In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding.

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."

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 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.

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

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.

A certain Debian patch for OpenSSH before 4.3p2-9etch3 on etch; before 4.6p1-1 on sid and lenny; and on other distributions such as SUSE uses functions that are not async-signal-safe in the signal handler for login timeouts, which allows remote attackers to cause a denial of service (connection slot exhaustion) via multiple login attempts. NOTE: this issue exists because of an incorrect fix for CVE-2006-5051.

Certain Red Hat Enterprise Linux (RHEL) 4 and 5 packages for OpenSSH, as signed in August 2008 using a legitimate Red Hat GPG key, contain an externally introduced modification (Trojan Horse) that allows the package authors to have an unknown impact. NOTE: since the malicious packages were not distributed from any official Red Hat sources, the scope of this issue is restricted to users who may have obtained these packages through unofficial distribution points. As of 20080827, no unofficial distributions of this software are known.

sshd in OpenSSH 4 on Debian GNU/Linux, and the 20070303 OpenSSH snapshot, allows remote authenticated users to obtain access to arbitrary SELinux roles by appending a :/ (colon slash) sequence, followed by the role name, to the username.

OpenSSH before 5.1 sets the SOREUSEADDR socket option when the X11UseLocalhost configuration setting is disabled, which allows local users on some platforms to hijack the X11 forwarding port via a bind to a single IP address, as demonstrated on the HP-UX platform.

OpenSSH 4.4 up to versions before 4.9 allows remote authenticated users to bypass the sshdconfig ForceCommand directive by modifying the .ssh/rc session file.

OpenSSH 4.3p2, and probably other versions, allows local users to hijack forwarded X connections by causing ssh to set DISPLAY to :10, even when another process is listening on the associated port, as demonstrated by opening TCP port 6010 (IPv4) and sniffing a cookie sent by Emacs.

A certain Red Hat modification to the ChrootDirectory feature in OpenSSH 4.8, as used in sshd in OpenSSH 4.3 in Red Hat Enterprise Linux (RHEL) 5.4 and Fedora 11, allows local users to gain privileges via hard links to setuid programs that use configuration files within the chroot directory, related to requirements for directory ownership.

The sshgssapiparseename function in gss-serv.c in OpenSSH 5.8 and earlier, when gssapi-with-mic authentication is enabled, allows remote authenticated users to cause a denial of service (memory consumption) via a large value in a certain length field. NOTE: there may be limited scenarios in which this issue is relevant.

The mmnewkeysfromblob function in monitorwrap.c in sshd in OpenSSH 6.2 and 6.3, when an AES-GCM cipher is used, does not properly initialize memory for a MAC context data structure, which allows remote authenticated users to bypass intended ForceCommand and login-shell restrictions via packet data that provides a crafted callback address.

IssueDescription:

In a Kerberos environment, OpenSSH allows remote, authenticated users to log in as another user if they are listed in a ~/.k5users file of that other user. This unexpectedly alters the system security policy, as expressed through the ~/.k5users file, because previously, users would have to log in locally, potentially requiring different forms of authentication, before they could use the ksu command to switch users.

sshd in OpenSSH 6.8 and 6.9 uses world-writable permissions for TTY devices, which allows local users to cause a denial of service (terminal disruption) or possibly have unspecified other impact by writing to a device, as demonstrated by writing an escape sequence.

The x11openhelper function in channels.c in ssh in OpenSSH before 6.9, when ForwardX11Trusted mode is not used, lacks a check of the refusal deadline for X connections, which makes it easier for remote attackers to bypass intended access restrictions via a connection outside of the permitted time window.

A denial of service vulnerability was found in openssh. The authpassword function in auth-passwd.c in sshd in OpenSSH before 7.3 does not limit password lengths for password authentication, which allows remote attackers to cause a denial of service (crypt CPU consumption) via a long string.

References:

http://seclists.org/oss-sec/2016/q3/215

Upstream fix:

https://github.com/openssh/openssh-portable/commit/fcd135c9df440bcd2d5870405ad3311743d78d97

Last updated 24 July 2024