p PatchFirst

PatchFirst · Vulnerabilidades recientes

Vulnerabilidades de libssh · Página 2

Vulnerabilidades publicadas para libssh en los últimos 30 días: 0. Incluidas en el catálogo KEV: 0.

Filtrar vulnerabilidades
Borrar filtros

Vulnerabilidades: 24

  1. CVE-2023-48795

    Media · CVSS 5.9EPSS 93,55%Código de explotación públicoCorrección disponible

    CVE-2023-48795

    The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with E

    • Actualiza a 0.9.6-2ubuntu0.22.04.2
    Publicación Actualización
  2. CVE-2023-2283

    Media · CVSS 6.5EPSS 1,06%Corrección disponible

    CVE-2023-2283

    A vulnerability was found in libssh, where the authentication check of the connecting client can be bypassed in the`pki_verify_data_signature` function in memory allocation problems. This issue may happen if there is insufficient memory or the memory usage is limited. The problem is caused by the return value `rc,` which is initialized to SSH_ERROR and later rewritten to save the return value of the function call `pki_key_check_hash_compatible.` The value of the variable is not changed between this point and the cryptographic verification. Therefore any error between them calls `goto error` returning SSH_OK.

    • Actualiza a 0.9.6-2ubuntu0.22.04.1
    Publicación Actualización
  3. CVE-2021-3634

    Media · CVSS 6.5EPSS 4,68%Corrección disponible

    CVE-2021-3634

    A flaw has been found in libssh in versions prior to 0.9.6. The SSH protocol keeps track of two shared secrets during the lifetime of the session. One of them is called secret_hash and the other session_id. Initially, both of them are the same, but after key re-exchange, previous session_id is kept and used as an input to new secret_hash. Historically, both of these buffers had shared length variable, which worked as long as these buffers were same. But the key re-exchange operation can also change the key exchange method, which can be based on hash of different size, eventually creating "secret_hash" of different size than the session_id has

    • Actualiza a 0.9.6-1
    Publicación Actualización

Comprueba tu servidor

Compara tu pila y las versiones instaladas con las bases actuales de vulnerabilidades.

Comprueba tu servidor →