[<prev] [next>] [day] [month] [year] [list]
Message-ID: <57c3641e-1425-4439-b517-95328ca25f3a@oracle.com>
Date: Fri, 27 Jun 2025 12:11:42 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Subject: libssh 0.11.2 security and bugfix release
https://www.libssh.org/2025/06/24/libssh-0-11-2-security-and-bugfix-release/
announces:
> This is a security release of libssh to address the following security issues:
>
> CVE-2025-4877 – Write beyond bounds in binary to base64 conversion functions
> CVE-2025-4878 – Use of uninitialized variable in privatekey_from_file()
> CVE-2025-5318 – Likely read beyond bounds in sftp server handle management
> CVE-2025-5351 – Double free in functions exporting keys
> CVE-2025-5372 – ssh_kdf() returns a success code on certain failures
> CVE-2025-5449 – Likely read beyond bounds in sftp server message decoding
> CVE-2025-5987 – Invalid return code for chacha20 poly1305 with OpenSSL backend
https://www.libssh.org/security/advisories/CVE-2025-4877.txt says:
> ===========================================================
> == Subject: Write beyond bounds in binary to base64 conversion functions
> ==
> == CVE ID#: CVE-2025-4877
> ==
> == Versions: All libssh versions
> ==
> == Summary: bin_to_base64() can run into an integer overflow on
> == 32-bit platforms.
> ==
> ===========================================================
>
> ===========
> Description
> ===========
>
> bin_to_base64() (src/base64.c) can experience an integer overflow and
> subsequent under allocation, leading to a write beyond bounds. The bug can
> occur only in 32-bit builds.
>
> The only problematic use case is ssh_get_fingerprint_hash() in case the API is
> (mis)used and a libssh consumer passes in an unexpectedly large input buffer.
>
> As a mitigation, the function bin_to_base64() is adjusted to not allow inputs
> larger than 256MB, which is aligned with other functions that process user
> input.
>
> ==================
> Patch Availability
> ==================
>
> Patches addressing the issues have been posted to:
> https://www.libssh.org/security/
> Additionally, libssh 0.11.2 have been issued
> as security releases to correct the defect. SSH administrators are
> advised to upgrade to these releases or apply the patch as soon
> as possible.
>
> ==================
> CVSSv3 calculation
> ==================
> CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L/E:U/RL:O/RC:C (3.9)
>
> ==========
> Workaround
> ==========
> Make sure the ssh_get_fingerprint_hash() is not used to encode arbitrary
> buffer larger than 1GB on 32-bit architecture.
>
> =======
> Credits
> =======
>
> Originally reported by Ronald Crane (Hackerone: tdp3kel9g) via Zippenhop LLC
> Patches provided by Jakub Jelen from the libssh team.
https://www.libssh.org/security/advisories/CVE-2025-4878.txt declares:
> ===========================================================
> == Subject: Use of uninitialized variable in privatekey_from_file()
> ==
> == CVE ID#: CVE-2025-4878
> ==
> == Versions: All libssh versions
> ==
> == Summary: The privatekey_from_file() uses an
> == uninitialized variable which can result in
> == return of an invalid private key.
> ==
> ===========================================================
>
> ===========
> Description
> ===========
>
> The privatekey_from_file() uses an uninitialized variable under certain
> conditions, such as if the file specified by the filename argument doesn't
> exist. This causes the code to return an invalid private key.
>
> This defect, in turn, might cause signing failure. The bug might also cause a
> Use-After-Free or corrupt the heap.
>
> Note that privatekey_from_file() is a deprecated function and shouldn't be used
> anymore!
>
> ==================
> Patch Availability
> ==================
>
> Patches addressing the issues have been posted to:
> https://www.libssh.org/security/
> Additionally, libssh 0.11.2 have been issued
> as security releases to correct the defect. SSH administrators are
> advised to upgrade to these releases or apply the patch as soon
> as possible.
>
> ==================
> CVSSv3 calculation
> ==================
> CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N/E:P/RL:O/RC:C (3.3)
>
> ==========
> Workaround
> ==========
> None
>
> =======
> Credits
> =======
>
> Originally reported by Ronald Crane (Hackerone: tdp3kel9g) via Zippenhop LLC
> Patches provided by Jakub Jelen from the libssh team.
https://www.libssh.org/security/advisories/CVE-2025-5318.txt discloses:
> ===========================================================
> == Subject: Likely read beyond bounds in sftp server handle management
> ==
> == CVE ID#: CVE-2025-5318
> ==
> == Versions: All libssh versions
> ==
> == Summary: sftp_handle() (sftpserver) can read beyond
> == bounds
> ==
> ===========================================================
>
> ===========
> Description
> ===========
>
> An incorrect comparison check allows to read beyond bounds in the sftp_handle()
> in the sftp server implementation. Thus an invalid pointer is returned as the
> handle and we try to continue using that.
>
> ==================
> Patch Availability
> ==================
>
> Patches addressing the issues have been posted to:
> https://www.libssh.org/security/
> Additionally, libssh 0.11.2 have been issued
> as security releases to correct the defect. SSH administrators are
> advised to upgrade to these releases or apply the patch as soon
> as possible.
>
> ==================
> CVSSv3 calculation
> ==================
> CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N/E:P/RL:O/RC:C (4.9)
>
> ==========
> Workaround
> ==========
> None
>
> =======
> Credits
> =======
>
> Originally reported by Ronald Crane (Hackerone: tdp3kel9g) via Zippenhop LLC
> Patches provided by Jakub Jelen from the libssh team.
https://www.libssh.org/security/advisories/CVE-2025-5351.txt divulges:
> ===========================================================
> == Subject: Double free in functions exporting keys
> ==
> == CVE ID#: CVE-2025-5351
> ==
> == Versions: libssh >= 0.10.0, built with OpenSSL >= 3.0
> ==
> == Summary: Exporting keys can cause a double free corruption on certain errors
> ==
> ===========================================================
>
> ===========
> Description
> ===========
>
> pki_key_to_blob() can cause a double free on certain errors when using OpenSSL
>>= 3.0. The function is used by different other functions which allow to
> export public or private keys to blobs or base64.
>
> The function is using the variable params without resetting it to NULL after
> free. In case of low-memory conditions when the allocation of string fails,
> the libssh calls the OSSL_PARAM_free() with the same arguments, which will
> likely crash.
>
> ==================
> Patch Availability
> ==================
>
> Patches addressing the issues have been posted to:
> https://www.libssh.org/security/
> Additionally, libssh 0.11.2 have been issued
> as security releases to correct the defect. SSH administrators are
> advised to upgrade to these releases or apply the patch as soon
> as possible.
>
> ==================
> CVSSv3 calculation
> ==================
> CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N/E:P/RL:O/RC:C (3.8)
>
> ==========
> Workaround
> ==========
> None
>
> =======
> Credits
> =======
>
> Originally reported by Ronald Crane (Hackerone: tdp3kel9g) via Zippenhop LLC
> Patches provided by Jakub Jelen from the libssh team.
https://www.libssh.org/security/advisories/CVE-2025-5372.txt states:
> ===========================================================
> == Subject: ssh_kdf() returns a success code on certain failures
> ==
> == CVE ID#: CVE-2025-5372
> ==
> == Versions: All libssh versions built with OpenSSL < 3.0
> ==
> == Summary: ssh_kdf() returns a success code on certain
> == failures.
> ==
> ===========================================================
>
> ===========
> Description
> ===========
>
> ssh_kdf() returns a success code on certain failures for libssh built with OpenSSL < 3.0
>
> This is caused by the alias of OpenSSL return value 0 (failure) with libssh
> SSH_OK (0). Returning success code from the ssh_kdf() function without
> initializing the output buffers can lead to use of uninitialized cryptographic
> keys and failing to encrypt/decrypt following communication.
>
> ==================
> Patch Availability
> ==================
>
> Patches addressing the issues have been posted to:
> https://www.libssh.org/security/
>
> Additionally, libssh 0.11.2 have been issued as security releases to correct
> the defect. SSH administrators are advised to upgrade to these releases or
> apply the patch as soon as possible.
>
> ==================
> CVSSv3 calculation
> ==================
> CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L/E:P/RL:O/RC:C (4.5)
>
> ==========
> Workaround
> ==========
> Build libssh with OpenSSL 3.0+.
>
> =======
> Credits
> =======
>
> Originally reported by Ronald Crane (Hackerone: tdp3kel9g) via Zippenhop LLC
> Patches provided by Jakub Jelen from the libssh team.
https://www.libssh.org/security/advisories/CVE-2025-5449.txt conveys:
> ===========================================================
> == Subject: Likely read beyond bounds in sftp server message decoding
> ==
> == CVE ID#: CVE-2025-5449
> ==
> == Versions: libssh 0.11.0 and 0.11.1
> ==
> == Summary: Incorrect packet length check in
> == sftp_decode_channel_data_to_packet() which
> == is used in the sftpserver implementation.
> ==
> ===========================================================
>
> ===========
> Description
> ===========
>
> Malicious clients can send invalid SFTP packets with payload size field set to
> value 0x7ffffffc (2GB - 3B). This value incorrectly passes the validity check
> on 32b platforms in the function sftp_decode_channel_data_to_packet().
>
> This is caused by integer overflow in the packet length check. But the wrong
> buffer bounds are not used for accessing beyond the buffer bounds as the
> following call to `ssh_buffer_add_data()` will already fail to allocate buffer
> of size > 256MB, leading to the self-DoS of the sftp server process.
>
> This is exploitable for sftp servers running on on 32b platforms only.
>
> ==================
> Patch Availability
> ==================
>
> Patches addressing the issues have been posted to:
> https://www.libssh.org/security/
> Additionally, libssh 0.11.2 have been issued
> as security releases to correct the defect. SSH administrators are
> advised to upgrade to these releases or apply the patch as soon
> as possible.
>
> ==================
> CVSSv3 calculation
> ==================
> CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L/E:U/RL:O/RC:C (3.8)
>
> ==========
> Workaround
> ==========
> None
>
> =======
> Credits
> =======
>
> Originally reported by Ronald Crane (Hackerone: tdp3kel9g) via Zippenhop LLC
> Patches provided by Jakub Jelen from the libssh team.
https://www.libssh.org/security/advisories/CVE-2025-5987.txt reveals:
> ===========================================================
> == Subject: Invalid return code for chacha20 poly1305 with OpenSSL backend
> ==
> == CVE ID#: CVE-2025-5987
> ==
> == Versions: libssh >= 0.10.0 built with OpenSSL
> ==
> == Summary: In the OpenSSL based implementation of
> == chacha20_poly1305_set_key() an invalid
> == error is returned if the cipher
> == initialization fails.
> ==
> ===========================================================
>
> ===========
> Description
> ===========
>
> If there is an error in initializing ChaCha20 cipher with OpenSSL, an invalid
> error code is returned. This can happen if there is an heap exhaustion. This
> error is not correctly detected and could allow libssh to use partially
> initialized cipher context.
>
> This is caused by the mismatch of return value meaning from OpenSSL and libssh,
> where OpenSSL error (rv=0) aliases with SSH_OK (0) and is returned directly
> from the function chacha20_poly1305_set_key(). This will likely cause error
> somewhere down the road.
>
> ==================
> Patch Availability
> ==================
>
> Patches addressing the issues have been posted to:
> https://www.libssh.org/security/
>
> Additionally, libssh 0.11.2 have been issued as security releases to correct
> the defect. SSH administrators are advised to upgrade to these releases or
> apply the patch as soon as possible.
>
> ==================
> CVSSv3 calculation
> ==================
> CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L/E:P/RL:O/RC:C (4.5)
>
> ==========
> Workaround
> ==========
> Disable chacha20-poly1305@...nssh.com cipher in case libssh is compiled with the OpenSSL backend.
>
> =======
> Credits
> =======
>
> Originally reported by Ronald Crane (Hackerone: tdp3kel9g) via Zippenhop LLC
> Patches provided by Jakub Jelen from the libssh team.
--
-Alan Coopersmith- alan.coopersmith@...cle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
