CVSS: 9.8EPSS: 0%CPEs: 4EXPL: 0CVE-2023-28531
https://notcve.org/view.php?id=CVE-2023-28531
ssh-add in OpenSSH before 9.3 adds smartcard keys to ssh-agent without the intended per-hop destination constraints. The earliest affected version is 8.9. • https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/AN2UDTXEUSKFIOIYMV6JNI5VSBMYZOFT https://security.gentoo.org/glsa/202307-01 https://security.netapp.com/advisory/ntap-20230413-0008 https://www.debian.org/security/2023/dsa-5586 https://www.openwall.com/lists/oss-security/2023/03/15/8 •
CVSS: 6.5EPSS: 0%CPEs: 10EXPL: 11CVE-2023-25136 – openssh: the functions order_hostkeyalgs() and list_hostkey_types() leads to double-free vulnerability
https://notcve.org/view.php?id=CVE-2023-25136
OpenSSH server (sshd) 9.1 introduced a double-free vulnerability during options.kex_algorithms handling. This is fixed in OpenSSH 9.2. The double free can be leveraged, by an unauthenticated remote attacker in the default configuration, to jump to any location in the sshd address space. One third-party report states "remote code execution is theoretically possible." OpenSSH server (sshd) v9.1 introdujo una vulnerabilidad de doble liberación durante el manejo de "options.key_algorithms". • https://github.com/Christbowel/CVE-2023-25136 https://github.com/nhakobyan685/CVE-2023-25136 https://github.com/adhikara13/CVE-2023-25136 https://github.com/jfrog/jfrog-CVE-2023-25136-OpenSSH_Double-Free https://github.com/H4K6/CVE-2023-25136 https://github.com/ticofookfook/CVE-2023-25136 https://github.com/malvika-thakur/CVE-2023-25136 https://github.com/Business1sg00d/CVE-2023-25136 http://www.openwall.com/lists/oss-security/2023/02/13/1 http://www.openwall.com/lists • CWE-401: Missing Release of Memory after Effective Lifetime CWE-415: Double Free •
CVSS: 3.7EPSS: 0%CPEs: 4EXPL: 0CVE-2021-36368
https://notcve.org/view.php?id=CVE-2021-36368
An issue was discovered in OpenSSH before 8.9. If a client is using public-key authentication with agent forwarding but without -oLogLevel=verbose, and an attacker has silently modified the server to support the None authentication option, then the user cannot determine whether FIDO authentication is going to confirm that the user wishes to connect to that server, or that the user wishes to allow that server to connect to a different server on the user's behalf. NOTE: the vendor's position is "this is not an authentication bypass, since nothing is being bypassed. ** EN DISPUTA ** Se ha detectado un problema en OpenSSH versiones anteriores a 8.9. Si un cliente está usando autenticación de clave pública con reenvío de agentes pero sin -oLogLevel=verbose, y un atacante ha modificado silenciosamente el servidor para que soporte la opción de autenticación None, entonces el usuario no puede determinar si la autenticación FIDO va a confirmar que el usuario desea conectarse a ese servidor, o que el usuario desea permitir que ese servidor sea conectado a un servidor diferente en nombre del usuario. NOTA: la posición del proveedor es que "esto no es una omisión de la autenticación, ya que no está omitiéndose nada" • https://bugzilla.mindrot.org/show_bug.cgi?id=3316 https://docs.ssh-mitm.at/trivialauth.html https://github.com/openssh/openssh-portable/pull/258 https://security-tracker.debian.org/tracker/CVE-2021-36368 https://www.openssh.com/security.html • CWE-287: Improper Authentication •
CVSS: 7.0EPSS: 0%CPEs: 18EXPL: 0CVE-2021-41617 – openssh: privilege escalation when AuthorizedKeysCommand or AuthorizedPrincipalsCommand are configured
https://notcve.org/view.php?id=CVE-2021-41617
sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user. sshd en OpenSSH versiones 6.2 hasta 8.x anteriores a 8.8, cuando son usadas determinadas configuraciones no predeterminadas, permite una escalada de privilegios porque los grupos complementarios no son inicializados como se espera. Los programas de ayuda para AuthorizedKeysCommand y AuthorizedPrincipalsCommand pueden ejecutarse con privilegios asociados a la pertenencia a grupos del proceso sshd, si la configuración especifica la ejecución del comando como un usuario diferente A flaw was found in OpenSSH. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user. Depending on system configuration, inherited groups may allow AuthorizedKeysCommand/AuthorizedPrincipalsCommand helper programs to gain unintended privileges, potentially leading to local privilege escalation. • https://bugzilla.suse.com/show_bug.cgi?id=1190975 https://lists.debian.org/debian-lts-announce/2023/12/msg00017.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6XJIONMHMKZDTMH6BQR5TNLF2WDCGWED https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KVI7RWM2JLNMWTOFK6BDUSGNOIPZYPUT https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/W44V2PFQH5YLRN6ZJTVRKAD7CU6CYYET https://security.netapp.com/advisory/ntap-20211014& • CWE-273: Improper Check for Dropped Privileges •
CVSS: 5.3EPSS: 2%CPEs: 5EXPL: 2CVE-2016-20012
https://notcve.org/view.php?id=CVE-2016-20012
OpenSSH through 8.7 allows remote attackers, who have a suspicion that a certain combination of username and public key is known to an SSH server, to test whether this suspicion is correct. This occurs because a challenge is sent only when that combination could be valid for a login session. NOTE: the vendor does not recognize user enumeration as a vulnerability for this product ** EN DISPTUTA ** OpenSSH versiones hasta 8.7, permite a atacantes remotos, que presentan la sospecha de que una determinada combinación de nombre de usuario y clave pública es conocida por un servidor SSH, comprobar si esta sospecha es correcta. Esto ocurre porque es enviado un desafío sólo cuando esa combinación podría ser válida para una sesión de inicio de sesión. NOTA: el proveedor no reconoce la enumeración de usuarios como una vulnerabilidad para este producto • https://github.com/openssh/openssh-portable/blob/d0fffc88c8fe90c1815c6f4097bc8cbcabc0f3dd/auth2-pubkey.c#L261-L265 https://github.com/openssh/openssh-portable/pull/270 https://github.com/openssh/openssh-portable/pull/270#issuecomment-920577097 https://github.com/openssh/openssh-portable/pull/270#issuecomment-943909185 https://rushter.com/blog/public-ssh-keys https://security.netapp.com/advisory/ntap-20211014-0005 https://utcc.utoronto.ca/~cks/space/blog/tech/SSHKeysAreInfoLeak https://www.openwall.com/lists •