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.

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

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.

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.

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.

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.

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.

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

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.

Last updated 24 July 2024

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.

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

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

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.

If PAM is configured to read user-specified environment variables and UseLogin=yes in sshdconfig, then a hostile local user may attack /bin/login via LDPRELOAD or similar environment variables set via PAM.

Upstream fix:

https://anongit.mindrot.org/openssh.git/commit/?id=85bdcd7c92fe7ff133bbc4e10a65c91810f88755

Debian advisory:

https://www.debian.org/security/2016/dsa-3550

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

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.

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.

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.

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

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

taskstats information may be used for gathering private information. E.g. for openssh and vsftpd daemons readcharacters/writecharacters may be used to learn the precise password length. Restrict it to processes being able to ptrace the target process. For TASKSTATSCMDATTRREGISTERCPUMASK the fix is euid check instead of a ptrace check as the handler is processed in the context of the target process, not the listener process'. When ptracetaskmayaccesscurrent() is introduced, it should be used instead of euid check. Currently there is a small race when a process temporarily changes its euid (e.g. to access user's files), until the process sets euid back user's processes may gather privileged process' statistics.

taskstats authorizedkeys presence infoleak PoC http://seclists.org/oss-sec/2011/q2/659

[0/2] restrict statistics information to user https://lkml.org/lkml/2011/6/24/88 [1/2] proc: restrict access to /proc/PID/io (CVE-2011-2495) https://patchwork.kernel.org/patch/916032/ [2/2] taskstats: restrict access to user (CVE-2011-2494) https://patchwork.kernel.org/patch/916042/

http://article.gmane.org/gmane.comp.security.oss.general/5337 Linus suggested returning accounting information at a 1k granularity instead.

Acknowledgements:

Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.

/proc/PID/io may be used for gathering private information. E.g. for openssh and vsftpd daemons wchars/rchars may be used to learn the precise password length.

[0/2] restrict statistics information to user https://lkml.org/lkml/2011/6/24/88 [1/2] proc: restrict access to /proc/PID/io (CVE-2011-2495) https://patchwork.kernel.org/patch/916032/ [2/2] taskstats: restrict access to user (CVE-2011-2494) https://patchwork.kernel.org/patch/916042/

taskstats authorizedkeys presence infoleak PoC http://seclists.org/oss-sec/2011/q2/659

Acknowledgements:

Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.

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

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

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

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,

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