RegreSSHion: ejecución remota de código (RCE) en servidores OpenSSH de Linux basados en glibc

 (qualys.com)
1 puntos por GN⁺ 2024-07-02 | 1 comentarios | Compartir por WhatsApp
  • Una condición de carrera en el manejador de señales del servidor OpenSSH sshd puede permitir que un cliente no autenticado provoque ejecución remota de código en servidores con la configuración por defecto, si no se autentica dentro del tiempo límite previo a la autenticación LoginGraceTime
  • Esta vulnerabilidad es una regresión de CVE-2006-5051, y reapareció entre 8.5p1 y antes de 9.8p1 cuando un commit de OpenSSH 8.5p1 de octubre de 2020 eliminó una protección en sigdie()
  • En Linux basado en glibc, syslog() llama funciones async-signal-unsafe como malloc() y free(), lo que puede llevar a RCE como root sin autenticación desde código privilegiado y no aislado de sshd
  • Las pruebas se realizaron en máquinas virtuales i386 y en una red estable con alrededor de 10 ms de jitter de paquetes; en Debian 12.5.0 con OpenSSH 9.2p1, obtener una shell root tomó en promedio unas 10,000 ejecuciones y entre 6 y 8 horas con MaxStartups=100 y LoginGraceTime=120
  • OpenSSH lo corrigió el 6 de junio de 2024 con el commit 81c1099; si actualizar o recompilar es difícil, LoginGraceTime 0 puede bloquear el RCE, aunque sigue existiendo riesgo de DoS por agotamiento de conexiones MaxStartups

Dónde ocurre la vulnerabilidad

  • El problema en sshd de OpenSSH comienza en el manejador SIGALRM que se ejecuta antes de la autenticación
    • Si el cliente no se autentica dentro de LoginGraceTime, el manejador SIGALRM se invoca de forma asíncrona
    • Ese manejador llama funciones que no son async-signal-safe, como syslog()
    • El valor por defecto es LoginGraceTime=120 segundos, y en versiones antiguas de OpenSSH era de 600 segundos
  • Esta vulnerabilidad es una regresión de CVE-2006-5051
    • CVE-2006-5051 fue una condición de carrera en el manejador de señales de OpenSSH anterior a 4.4 reportada por Mark Dowd en 2006
    • En octubre de 2020, el commit 752250c de OpenSSH 8.5p1 eliminó por error #ifdef DO_LOG_SAFE_IN_SIGHAND de sigdie()
  • El impacto por versión está claramente delimitado
    • Antes de OpenSSH 4.4p1: es vulnerable si no se backportearon los parches relacionados con CVE-2006-5051 o CVE-2008-4109
    • OpenSSH 4.4p1 y hasta antes de 8.5p1: no es vulnerable a esta carrera porque sigdie() se cambió por una llamada segura a _exit(1)
    • OpenSSH 8.5p1 y hasta antes de 9.8p1: vuelve a ser vulnerable por la eliminación de la protección

Entornos afectados y excepciones

  • El objetivo de la explotación remota es Linux basado en glibc
    • El syslog() de glibc llama internamente funciones async-signal-unsafe como malloc() y free()
    • El código vulnerable está en código privilegiado de sshd, sin sandbox y ejecutándose con privilegios completos
    • Como resultado, es posible ejecutar código remoto como root sin autenticación
  • No se investigaron otras libc ni otros sistemas operativos
  • OpenBSD no es vulnerable
    • El manejador SIGALRM de OpenBSD llama syslog_r() en lugar de syslog()
    • syslog_r() es una versión más segura para señales asíncronas creada por OpenBSD en 2001

Supuestos de la investigación de explotación remota

  • Para explotar esta condición de carrera en remoto, hay que resolver tres problemas
    • Se necesita una ruta de código que deje a sshd en un estado inconsistente si SIGALRM interrumpe en el momento adecuado
    • Hay que llegar a esa ruta de código y aumentar la probabilidad de interrumpirla en el momento correcto
    • Ese timing debe poder ajustarse incluso en una red remota
  • La investigación comenzó en un entorno i386 con versiones antiguas de OpenSSH y luego se extendió a versiones recientes, en lugar de enfrentarse de entrada a las mitigaciones más modernas
  • Las condiciones experimentales tienen limitaciones claras
    • Solo se probaron máquinas virtuales, no servidores bare-metal
    • La red era un enlace relativamente estable con unos 10 ms de jitter de paquetes
    • Varias partes del exploit todavía podrían mejorarse
    • Ya comenzó el trabajo del exploit para amd64, pero es mucho más difícil por un ASLR más fuerte

Pruebas contra OpenSSH antiguo

  • Debian 3.0r6, OpenSSH 3.4p1

    • El objetivo fue SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3, un entorno de 2005 sobre Debian 3.0r6
    • Esa versión de Debian fue la primera con privilege separation activado por defecto y ya incluía los principales parches de vulnerabilidades de la época
    • La explotación aprovecha la interrupción de free() y un estado inconsistente del heap
      • Una llamada a free() en el código de parsing de claves públicas se interrumpe con SIGALRM
      • Después se aprovecha el estado inconsistente del heap en otro free() dentro de packet_close()
    • glibc 2.2.5 no tenía mitigaciones para la técnica unlink() de Solar Designer
    • El ataque sobrescribe __free_hook para redirigir el flujo de ejecución hacia la dirección del shellcode en el heap
    • Esta versión de Debian no tiene ASLR ni NX
    • Tras mejorar el timing, se requirieron en promedio unas 10,000 ejecuciones
    • Con MaxStartups=10 y LoginGraceTime=600, obtener una shell root remota tomó alrededor de una semana en promedio

  • Ubuntu 6.06.1, OpenSSH 4.2p1

    • El objetivo fue SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3, un entorno de 2006 sobre Ubuntu 6.06.1
    • Fue la última versión de Ubuntu que seguía siendo vulnerable a CVE-2006-5051
    • glibc 2.3.6 toma un lock obligatorio al entrar a funciones de la familia malloc, así que interrumpir un malloc y luego abusar de otra llamada malloc termina en deadlock
    • La ruta final de explotación usa PAM
      • pam_start() establece el puntero global sshpam_handle de sshd
      • Si _pam_add_handler() se interrumpe, puede quedar sin inicializar el campo next
      • Cuando pam_end() se llama desde el manejador SIGALRM, puede pasar un puntero arbitrario a free()
    • La antigua técnica unlink() de glibc ya estaba bloqueada, así que se usó la versión fastbin de House of Mind de Malloc Maleficarum
    • La fake arena apunta a .got.plt de sshd y sobrescribe la entrada de _exit() con la dirección del shellcode en el heap
    • El heap de esta versión de Ubuntu es ejecutable por defecto
    • Se requirieron en promedio unas 10,000 ejecuciones
    • Con MaxStartups=10 y LoginGraceTime=120, obtener una shell root remota tomó entre 1 y 2 días en promedio
    • Un atacante con mala suerte puede bloquear por deadlock las 10 conexiones de MaxStartups antes de obtener la shell root

Prueba en Debian 12.5.0, OpenSSH 9.2p1

  • syslog() y la ruta malloc de glibc

    • El objetivo fue SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2, el entorno stable actual de 2024 en Debian 12.5.0
    • Este entorno es vulnerable a la regresión de CVE-2006-5051
    • El manejador SIGALRM en esta versión no llama packet_close() ni pam_end(), sino que termina en la ruta de syslog()
      • grace_alarm_handler() llama sigdie()
      • sigdie() llama syslog() pasando por sshlogv() y do_log()
    • El syslog() de Debian glibc 2.36 llama malloc la primera vez que se ejecuta
      • En la ruta __localtime64_r() se llama __tzfile_read()
      • fopen() llama malloc(304) para una estructura FILE
      • También se llama malloc(4096) para un buffer interno de lectura
    • Desde octubre de 2017, malloc de glibc ya no toma locks obligatorios en escenarios de un solo hilo
    • En procesos de un solo hilo como sshd, esto abre la posibilidad de explotar contención en malloc

  • Condiciones de ASLR y limitaciones de i386

    • El entorno Debian 12.5.0 i386 tiene una debilidad de ASLR
    • El PIE de sshd, el heap, la mayoría de las librerías y la stack suelen estar aleatorizados
    • Pero glibc siempre se mapea en 0xb7200000 o 0xb7400000
    • Es posible acertar la dirección de glibc con una probabilidad del 50%
    • El exploit asume que glibc está mapeada en 0xb7400000
    • Esto se debe a que esa dirección era un poco más frecuente que 0xb7200000

  • Inconsistencia del heap y explotación de la estructura FILE

    • La ruta malloc elegida es la ruta split que divide un free chunk grande en dos
    • Se generan el chunk que se devuelve y un chunk remainder
    • Si SIGALRM interrumpe después de enlazar el remainder chunk en la unsorted list pero antes de inicializar su campo size, se produce una inconsistencia del heap
    • El atacante controla el campo size del remainder chunk usando datos residuales de una asignación previa del heap
    • Hace que el remainder chunk parezca más grande de lo real y se superponga con otros chunks del heap
    • Cuando malloc dentro del manejador SIGALRM usa ese chunk, la memoria del heap se corrompe
    • El objetivo es la estructura FILE que fopen() asigna en el heap dentro de __tzfile_read()
      • Con corrupción limitada del heap, se sobrescribe 1 byte de _vtable_offset de la estructura FILE
      • Eso hace que las funciones libio de glibc busquen el puntero de vtable en otro offset, no en el habitual
      • El atacante controla en esa ubicación un fake vtable pointer y un puntero _codecvt mediante datos residuales de asignaciones previas del heap
    • En glibc i386, esta técnica permite llamar un puntero de función arbitrario __fct durante __fread_unlocked()
    • Parece que glibc amd64 no usa _vtable_offset

  • Layout del heap y 27 ventanas de carrera

    • Como una sola ventana de carrera pequeña no basta para ganar la condición de carrera, se crean 27 pares de large hole y small hole
    • 28 pares superarían PACKET_MAX_SIZE de 256 KB
    • El paquete final fuerza la secuencia malloc(~4KB), malloc(304), malloc(~4KB), malloc(304)
    • Si el split de cada large hole se interrumpe en el momento exacto, el fopen() del manejador SIGALRM asigna el small hole correspondiente como estructura FILE
    • Para construir el layout del heap se usa el código de parsing de claves públicas de sshd
      • Las rutas cert_parse() y cert_free() ejecutan secuencias de malloc() y free() casi arbitrarias
      • Como no se encontró una memory leak, se usaron chunks de tcache como barrier chunk temporal
    • Se envían cinco tipos de paquetes de clave pública
      • a/ hacen que asignaciones de heap no controlables entren como chunks de tcache
      • b/ crean 27 pares de large/small hole y barrier chunk
      • c/ escriben fake header, fake footer, fake vtable y el puntero _codecvt
      • d/ asignan y liberan una cadena grande de casi 256 KB para mover los holes desde la unsorted list a cada bin de malloc
      • e/ fuerzan la secuencia final de malloc y abren 27 ventanas pequeñas de carrera

  • Estrategia de timing para versiones modernas

    • La estrategia de timing basada en feedback usada en versiones antiguas no funcionó contra OpenSSH 9.2p1
    • El quinto parsing de clave pública tarda unos 10 ms, así que la ventana de carrera grande se vuelve demasiado amplia
    • user_specific_delay(), introducida en OpenSSH 7.8p1, retrasa la respuesta hasta unos 9 ms y rompe el feedback anterior
    • La nueva estrategia compara el tiempo de respuesta de dos tipos de errores intencionales
      • Se envía un paquete que provoca un error justo antes del parsing de la clave pública
      • Se envía un paquete que provoca un error justo después del parsing de la clave pública
      • La diferencia entre ambos tiempos mide el tiempo del último parsing de clave pública
    • Con esta estrategia se gana la condición de carrera en promedio tras unas 10,000 ejecuciones
    • Con MaxStartups=100 y LoginGraceTime=120, ganar la condición de carrera toma entre 3 y 4 horas en promedio
    • Por ASLR, obtener la shell root remota requiere entre 6 y 8 horas en promedio

Estado del exploit en amd64

  • El objetivo amd64 es Rocky Linux 9
    • La imagen objetivo es Rocky-9.4-x86_64-minimal.iso
    • OpenSSH 8.7p1 es vulnerable a esta condición de carrera en el manejador de señales
    • glibc se mapea en múltiplos de 2 MB por una debilidad de ASLR, lo que vuelve más potente el partial pointer overwrite
  • El syslog() de glibc 2.34 en Rocky Linux 9 llama internamente __open_memstream()
    • Asigna una estructura FILE en el heap con malloc()
    • También llama calloc(), realloc() y free(), dando más margen de maniobra
  • A partir del primitive de corrupción de heap, las dos estructuras FILE asignadas en heap y 21 bits fijos de la dirección de glibc, consideran posible la explotación también en amd64
    • Estiman que tardará más que las 6 a 8 horas de i386, pero esperan que sea menos de una semana
  • También hay una observación aparte sobre Ubuntu 24.04
    • Ubuntu 24.04 no vuelve a aleatorizar el ASLR del proceso hijo de sshd, sino que lo aleatoriza solo una vez al arrancar
    • La causa se rastrea al systemd-socket-activation.patch que desactiva rexec_flag
    • En general es una mala decisión, pero en esta vulnerabilidad impide la explotación porque syslog() dentro del manejador SIGALRM no es la primera llamada a syslog(), así que no invoca funciones malloc
    • Parche relacionado: https://git.launchpad.net/ubuntu/+source/…

Parche y mitigaciones

  • OpenSSH corrigió esta condición de carrera el 6 de junio de 2024 con el commit 81c1099
    • 81c1099: agrega una función para que sshd(8) penalice el comportamiento problemático del cliente
    • Mueve el código async-signal-unsafe fuera del manejador SIGALRM de sshd hacia el proceso listener para procesarlo de forma síncrona
  • Esta corrección depende del gran commit 81c1099 y del aún mayor commit de defense-in-depth 03e3de4, así que podría ser difícil de backportear
  • Si backportearlo es complicado, se puede eliminar o comentar el código async-signal-unsafe en sshsigdie() para que solo llame _exit(1)
  • Si no es posible actualizar ni recompilar, se puede poner LoginGraceTime en 0 en el archivo de configuración
    • Esa configuración bloquea la ejecución remota de código descrita en este advisory
    • Pero deja el sistema vulnerable a DoS por agotamiento de todas las conexiones MaxStartups

Cronograma de divulgación

  • 2024-05-19: se contactó a los desarrolladores de OpenSSH y luego siguieron iteraciones de parche y revisión
  • 2024-06-20: se contactó a distros@openwall
  • 2024-07-01: se publicó en la fecha de lanzamiento coordinada

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-07-02
Opiniones de Hacker News

  • Curiosamente, parece que la corrección del RCE se “coló” públicamente hace casi un mes
    Cuando PerSourcePenalties está activado, sshd(8) vigila el estado de salida de los procesos hijos de sesión antes de la autenticación y registra condiciones como fallos repetidos de autenticación o caídas de sshd como penalizaciones durante cierto tiempo para la dirección del cliente
    https://github.com/openssh/openssh-portable/commit/81c1099d2...
    Más que un parche que pueda analizarse al revés y dar pistas al atacante, parece un efecto secundario bastante ingenioso: cambia la estructura del binario, elimina una vulnerabilidad concreta y además mitiga toda esa familia de exploits

    • Eso no es la corrección del RCE; la verdadera corrección del RCE es esta: https://news.ycombinator.com/item?id=40843865
      El cambio anterior era una función anunciada para manejar conexiones basura, y solo mitiga también esta vulnerabilidad al hacer más difícil ganar la condición de carrera
      Discusión previa: https://news.ycombinator.com/item?id=40610621
    • Me pregunto si esta corrección ya fue incorporada o tomada por las distribuciones
    • Me parece interesante que este comentario, aunque era incorrecto y fue corregido justo abajo, haya quedado en la parte superior durante 2 días
      Me pregunto si la gente solo lee el primer comentario del hilo, lo vota y se va con una impresión equivocada

  • Un fragmento de las notas de lanzamiento de OpenSSH es interesante
    “Se ha demostrado una explotación exitosa en sistemas Linux/glibc de 32 bits con ASLR activado. En condiciones de laboratorio, el ataque requiere mantener conexiones continuas hasta el máximo permitido por el servidor durante un promedio de 6 a 8 horas. Se cree que también es posible en sistemas de 64 bits, pero aún no se ha demostrado. Es probable que estos ataques mejoren.”
    https://www.openssh.com/releasenotes.html

  • Al ver el diff [1] que introdujo el bug, según el análisis el problema es que sigdie() pasó de estar envuelto en #ifdef DO_LOG_SAFE_IN_SIGHAND a una refactorización en la que sshsigdie() llama directamente a sshlogv(), y se perdió el #ifdef
    ¿Qué podría haberlo evitado? ¿Había que revisar más los pull requests? Me sorprende que un software del que depende el mundo entero para conexiones seguras parezca estar mantenido, en la práctica, por dos personas [2]
    [1] https://github.com/openssh/openssh-portable/commit/752250caa...
    [2] https://github.com/openssh/openssh-portable/graphs/contribut...

    • A posteriori es fácil decir qué se podría haber hecho para evitarlo
      En este caso, habría ayudado que hubiera un comentario explicando por qué se necesitaba el #ifdef. Por ejemplo: “el código aquí debe ser seguro para señales asíncronas, y el estado de los locks puede ser indeterminado”
      Aunque, para ser honestos, getrlimit tampoco aparece en esta lista: https://man7.org/linux/man-pages/man7/signal-safety.7.html
      Aun así, si se hubiera eliminado o modificado código con un comentario sobre seguridad frente a señales asíncronas, probablemente habría llamado la atención en la revisión. En el código citado, solo algo como SAFE_IN_SIGHAND sugiere que este código debe ser seguro dentro de un manejador de señales
    • Como OpenBSD refactorizó el sistema para usar una función syslog reentrante y segura para señales asíncronas, es posible que quien escribió este código simplemente haya asumido que el cambio era seguro
      Puede que haya olvidado o no supiera que en otras plataformas que los desarrolladores de OpenBSD ssh en realidad no afirman soportar, todavía se usan funciones que no son seguras para señales asíncronas
    • Es open source. Si sientes que puedes hacerlo mejor, eres libre de hacer un fork
      No tienes derecho a recibir nada de los desarrolladores open source. Ellos también pueden equivocarse y pueden decidir por sí mismos cuántos mantenedores o revisores tener
      https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
    • La frase “software del que depende el mundo entero para conexiones seguras, mantenido en la práctica por dos personas” inevitablemente me recuerda a este xkcd: https://xkcd.com/2347/
    • Había varias formas de evitarlo
      1. Usar un lenguaje de programación adecuado que no permita configurar funciones arbitrarias como manejadores de señales. En libc común es claramente inseguro, y en Rust o Java seguros no puedes hacerlo de esa manera
      2. Usar una libc bien implementada, en la que llamar a funciones no seguras para señales asíncronas provoque como mucho un deadlock y no corrupción de memoria. Es relativamente fácil si el código que se ejecuta dentro de una señal se trata como un hilo separado desde el punto de vista del acceso al almacenamiento local de hilo; y si no hay mutexes globales, o si se puede reanudar el código interrumpido que sostenía el mutex, incluso se puede evitar el deadlock
      3. Pensar al cambiar y aprobar código. No hacer como quienes eliminaron un #ifdef sin justificación, como en [1]
      4. Usar, en lugar de OpenSSH, software simple y bien diseñado escrito por buenos programadores

  • También vale la pena leer las notas de la versión: https://www.openssh.com/releasenotes.html
    En realidad, esto es una variante de un interesante bug de condición de carrera de señales. Según el informe de la vulnerabilidad, “OpenBSD no es especialmente vulnerable porque su manejador de SIGALRM llama a syslog_r(), una versión de syslog() más segura para señales asíncronas que OpenBSD creó en 2001”.
    Es decir, una mitigación de seguridad de señales llevó a los desarrolladores de OpenBSD a poner código no trivial dentro de un manejador de señales, y cuando ese código se portó a otros sistemas, dejó de ser seguro. Si se hubiera refactorizado para minimizar el código dentro del manejador de señales, siguiendo la sabiduría general y las convenciones del código Unix, este bug se habría evitado.

    • Theo de Raadt hizo una observación bastante acertada sobre la prevención de este bug y otros similares: ningún manejador de señales debería llamar a funciones que no sean llamadas al sistema seguras para señales.
      Con el tiempo, es demasiado fácil que en algún punto de las llamadas transitivas se mezcle una llamada que no sea segura para señales asíncronas, y tampoco siempre es evidente que esa ruta sea alcanzable desde un contexto de señal.
    • Es muy probable que entre los administradores de sistemas jóvenes o pasantes que tengan que parchear esta vulnerabilidad haya bastantes que ni siquiera habían nacido cuando OpenBSD implementó esta solución.

  • Después de actualizar mis instancias de OpenSSH, vi que estaban enlazadas contra musl y no contra glibc, así que revisé si syslog(3) de musl también hace asignaciones y, por lo tanto, si sería fácilmente explotable de la misma manera.
    A simple vista no parece ser así: https://github.com/bminor/musl/blob/master/src/misc/syslog.c
    Todo lo que hay ahí son variables en la pila o variables estáticas protegidas con locks para evitar reentradas. Las llamadas a {d,sn,vsn}printf() tampoco asignan memoria en musl, aunque en glibc podrían hacerlo. ¿Se me está escapando algo?

    • Confirmación de Rich: https://fosstodon.org/@musl/112711796005712271
    • Si el juicio sobre las asignaciones es correcto, el peor caso probablemente sería un interbloqueo porque el lock no es recursivo.
      Aun así, si hay un interbloqueo dentro de sigalrm, podría impedir la limpieza de conexiones y terminar en una denegación de servicio.

  • Ya salió un parche para FreeBSD.
    No está claro si está afectado. La explotación conocida solo era posible en glibc y FreeBSD no usa glibc, pero es mejor ir por lo seguro.
    https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04...

  • Según el informe, si no puedes actualizar o recompilar sshd, basta con establecer LoginGraceTime en 0 en el archivo de configuración para corregir esta condición de carrera del manejador de señales.
    En ese caso, sshd quedaría vulnerable a una denegación de servicio por agotamiento de todas las conexiones de MaxStartups, pero quedaría a salvo de la ejecución remota de código descrita en este aviso.
    Por lo tanto, configurar LoginGraceTime 0 en sshd_config parece servir como mitigación.

    • Espera, en https://www.man7.org/linux/man-pages/man5/sshd_config.5.html dice que un valor de 0 significa que no hay límite de tiempo.
      ¿Entonces no sería peor?
    • Una solución alternativa más realista podría ser hacer que el tiempo de gracia sea lo suficientemente largo o, por el contrario, ajustar el número máximo de conexiones para que la probabilidad de un ataque exitoso quede tan lejos en el futuro que no valga la pena intentarlo.
    • ¿Reiniciar sshd en frío cada hora también podría reducir la posibilidad de explotación o hacerla más difícil?

  • Ya salió un parche para Debian 12, y Debian 11 no está afectado.
    https://security-tracker.debian.org/tracker/CVE-2024-6387

    • Focal (20.04) no parece ser una versión afectada, mientras que Jammy (22.04) sí parece estarlo.
    • Acabo de ejecutar apt update y upgrade en un servidor Debian 12, y lo único que se actualizó fueron los paquetes de OpenSSH.
    • Confirmé que también llegó una versión actualizada de openssh a Pi OS bullseye.

  • Un hallazgo realmente muy bueno.
    Aunque no estoy en una posición en la que trabaje directamente en esto, a menudo se siente que, en la investigación de seguridad, para “ganar” no basta con encontrar y corregir un problema aislado, o recibir una recompensa por él, sino que hay que encontrar toda la cadena que llegue hasta el acceso remoto.
    Me pregunto si no debería ser suficiente encontrar un solo hueco, por ejemplo una corrupción de memoria o un escape de sandbox. Hoy hay tantos problemas pequeños que quizá, para que la gente realmente los tome en serio o pague bug bounties, haya que mostrar el hack completo hasta el final.

    • Hay muchos aspirantes a investigadores de seguridad que encuentran problemas no explotables y aun así exigen un número CVE, reconocimiento e incluso recompensas.
      Por ejemplo, si una app se crashea cuando recibe una entrada de confianza mal formada, pero por la naturaleza de esa app no está pensada para quedar expuesta a un adversario y, en la práctica, eso tampoco ocurriría, la mayoría lo vería simplemente como un bug, no como un bug de seguridad. Sería bueno corregirlo, pero no está al mismo nivel, y ese tipo de cosas tampoco es tan difícil de encontrar.
      Por eso hace falta distinguir entre bugs de seguridad “reales” como este caso y bugs sin impacto de seguridad, y es muy importante demostrar que el problema es explotable.
      Como siempre habrá una cantidad interminable de bugs sin impacto de seguridad, no parece que este requisito de demostración vaya a desaparecer pronto.
    • Viéndolo desde otra perspectiva: supongamos que creé una biblioteca de serialización/deserialización que se vuelve vulnerable si le meto datos no confiables.
      Es así por diseño, y los usuarios pueden serializar y deserializar cualquier cosa, incluso funciones lambda. Mi biblioteca solo está pensada para procesar datos de fuentes confiables.
      Hasta donde sé, nadie usa esta biblioteca para procesar datos no confiables. Una biblioteca popular usa la mía para leer archivos de configuración, pero ellos consideran esos archivos de configuración como datos confiables. Y no es mi trabajo controlar cómo otras personas usan mi biblioteca.
      En ese caso, ¿sería correcto registrar un CVE de máxima prioridad diciendo que mi proyecto tiene una vulnerabilidad de ejecución remota de código?
    • Me tocó estar del lado de quien reporta, y una “vulnerabilidad explotable” y una “debilidad de seguridad que algún día podría derivar en una vulnerabilidad explotable” son cosas muy distintas.
      Las recompensas siempre se pagan por la primera categoría. Los reportes de la segunda categoría, si no incluyen una prueba de concepto o una demostración de explotabilidad, incluso pueden dañar la reputación o la señal.
      Las debilidades que no se vuelven explotables hasta que se cumplen ciertas condiciones existen casi siempre. Incluso en competencias como Pwn2Own, suele verse cómo se encadenan varias vulnerabilidades hasta tomar control del dispositivo, y cómo algunas quedan sin parchear durante años. Los investigadores a veces se guardan esas debilidades durante mucho tiempo para maximizar el impacto.
      Es triste, pero así es la realidad.
    • Como dice el adagio de seguridad: POC || GTFO
    • Los compradores pagan por resultados. Los vendors sí pagan también por los eslabones individuales de la cadena.

  • Notas de la versión de OpenSSH: https://www.openssh.com/txt/release-9.8
    Parche mínimo para quienes no pueden o no quieren actualizar: https://marc.info/?l=oss-security&m=171982317624594&w=2

    • “Se considera posible explotarlo en sistemas de 64 bits, pero por el momento no se ha demostrado”