Cómo mi rsync mínimo y seguro en memoria hecho en Go evita vulnerabilidades

 (michael.stapelberg.ch)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • gokrazy/rsync es una implementación mínima de rsync escrita en Go, revisada con base en 12 vulnerabilidades de rsync divulgadas en enero de 2025 y mayo de 2026
  • La verificación de límites y la inicialización en cero de Go convierten desbordamientos de heap y filtraciones de información de la pila en panic o valores inofensivos, aunque un panic todavía puede convertirse en una denegación de servicio
  • El recorrido de rutas y la familia TOCTOU tienen como defensa clave APIs de archivos resistentes al recorrido como os.Root de Go 1.24, y gokrazy/rsync ya migró por completo a ese enfoque
  • La estrategia de implementación mínima evita vulnerabilidades relacionadas con funciones no implementadas como --inc-recursive, compresión, --safe-links, proxy y ACL de nombres de host, reduciendo así la superficie de ataque
  • La mayoría de las vulnerabilidades surgieron por falta de validación y complejidad excesiva, y para casos de uso simples una implementación simple puede ser más adecuada

Contexto y alcance

  • En enero de 2025, varios investigadores de seguridad divulgaron un total de 6 vulnerabilidades de seguridad en el rsync upstream de Samba, y algunas permitían ejecución arbitraria de código y filtración de archivos
  • El punto central de la revisión es si gokrazy/rsync, una implementación compatible y mínima escrita en Go, realmente puede evitar estas familias de vulnerabilidades
  • El análisis cubre 12 vulnerabilidades combinando el lote de enero de 2025 y el lote de mayo de 2026
  • Si estás ejecutando rsync upstream en producción, debes actualizar a 3.4.3 o superior, y gokrazy/rsync debe actualizarse a v0.3.3 o superior
  • gokrazy/rsync fue escrito para ofrecer los paquetes de software del proyecto de investigación de distribuciones Linux distri en router7, y router7 está basado en la plataforma de appliances en Go gokrazy
  • Al principio solo existía el servidor rsync, pero ahora admite todas las direcciones y se usa en varios servidores gokrazy/rsync como funcionalidad básica de rsync que puede enlazarse a programas en Go

Vulnerabilidades de enero de 2025

  • CVE-2024-12084: desbordamiento de búfer en el heap, severidad 9.8

    • rsync comparaba la longitud del checksum recibido por la red con MAX_DIGEST_LEN, pero su estructura de datos interna siempre usaba un búfer de 16 bytes: char sum2[SUM_LENGTH]
    • MAX_DIGEST_LEN puede ser mayor si se compila con soporte para checksums SHA256 o SHA512, así que un atacante podía escribir hasta 48 bytes más allá del límite del búfer sum2
    • El problema se introdujo en septiembre de 2022 con el commit ae16850, que agregó soporte para checksums SHA256/SHA512
    • La corrección upstream reemplaza sum2 por un sum2_array asignado dinámicamente y hace la asignación y validación con xfer_sum_len, la longitud del checksum del algoritmo de transferencia
    • En Go, una verificación de límites incorrecta no termina en un desbordamiento de búfer en el heap, sino en un panic por la verificación de límites del runtime
    • gokrazy/rsync también tenía una validación faltante del encabezado sum, pero no era una confusión de tamaños, y si se cambia ChecksumLength a 512, el runtime de Go genera panic: runtime error: slice bounds out of range [:512] with length 16
    • Como un crash completo del servidor no es un modo de falla deseable, se agregó la verificación de límites faltante para convertir el panic en error

  • CVE-2024-12085: filtración de información de la pila para evadir ASLR, severidad 7.5

    • Debido a la misma validación faltante que en CVE-2024-12084, un atacante podía elegir un algoritmo de checksum corto y luego afirmar que había enviado un checksum más largo
    • Según el reporte de seguridad de Google, la combinación del desbordamiento de búfer en el heap con la filtración de información podía permitir que un cliente con acceso de solo lectura anónimo ejecutara código arbitrario en la máquina del servidor rsync
    • hash_search() creaba el digest del chunk en char sum2[MAX_DIGEST_LEN] en la pila y lo comparaba con memcmp(), pero como el búfer local sum2 en la pila no se inicializaba, los bytes restantes podían contener contenido de la pila
    • Un cliente malicioso podía filtrar 1 byte por cada descarga de archivo, y los datos filtrados podían incluir punteros a objetos del heap, stack cookie, variables locales, punteros a variables globales y return pointer
    • “Some checksum buffer fixes” evitó que s->s2length, controlado por el atacante, pudiera ser mayor que la longitud del checksum de transferencia, y “prevent information leak off the stack” inicializó en 0 la memoria de sum2
    • Go inicializa todas las variables con su zero value, así que no se ve afectado por esta vulnerabilidad, y gokrazy/rsync implementa la versión 27 del protocolo, no la versión 30 donde se introdujo la selección de checksums distintos de MD4

  • CVE-2024-12087: path traversal mediante enlaces simbólicos, severidad 7.5

    • Según el reporte de seguridad de Google, cuando la sincronización de enlaces simbólicos está habilitada con -l o -a (--archive), un servidor malicioso puede hacer que el cliente escriba archivos arbitrarios fuera del directorio de destino
    • El ataque funciona enviando varias listas de archivos en modo --inc-recursive: en la primera lista, symlink aparece como directorio, y en la siguiente se cambia el mismo nombre por un enlace simbólico que apunta fuera del directorio de destino
    • Go por sí mismo no evita esta vulnerabilidad, porque la causa es un error lógico: no se volvió a validar después de fusionar múltiples listas de archivos
    • La corrección upstream agrega la validación faltante
    • gokrazy/rsync no se ve afectado porque no implementa el modo de recursión incremental (--inc-recursive)
    • La recursión incremental permite procesar el conjunto completo de archivos de forma “windowed” sin escanearlo entero antes de empezar la transferencia, pero implica un trade-off entre complejidad de implementación y uso de recursos

  • CVE-2024-12088: bypass de --safe-links, severidad 7.5

    • Según el reporte de seguridad de Google, --safe-links es una función que verifica que los enlaces simbólicos recibidos del servidor apunten dentro del directorio de destino
    • El bypass ocurre porque no se tiene en cuenta si hay otros enlaces simbólicos en medio de la ruta de destino del enlace simbólico
    • Por ejemplo, si existen {DESTINATION}/a -> . y {DESTINATION}/foo -> a/a/a/a/a/a/../../, foo en realidad apunta fuera del directorio de destino, pero unsafe_symlink() asume que a/ es un directorio y lo considera seguro
    • La corrección upstream hace unsafe_symlink() más estricto para no permitir ../ salvo al inicio de la ruta
    • Go por sí mismo no evita una función de validación incorrecta, y gokrazy/rsync no es vulnerable porque todavía no implementa la función --safe-links

  • CVE-2024-12086: filtración arbitraria de archivos, severidad 6.8

    • El receiver de rsync, en modo cliente, no saneaba los nombres de archivo proporcionados por el sender de rsync y no impedía abrir archivos fuera del árbol de destino
    • Un sender malicioso podía indicarle al receiver que comparara los checksums de archivos arbitrarios fuera del árbol de destino y, observando la respuesta del receiver a checksums de 1 byte, podía filtrar archivos arbitrarios
    • Según el reporte de seguridad de Google, si un cliente se conecta a un servidor malicioso, el servidor puede filtrar el contenido de archivos arbitrarios de la máquina cliente
    • La corrección upstream valida las rutas proporcionadas por el sender para impedir abrir archivos fuera del árbol de destino
    • Go sí tiene APIs que pueden ayudar a evitar esto, y una defensa relacionada que se menciona es os.Root de Go
    • gokrazy/rsync no es vulnerable porque implementa la versión 27 del protocolo, no la versión 29 donde se introdujo la función de fuzzy matching

  • CVE-2024-12747: condición de carrera con enlaces simbólicos, severidad 5.6

    • Según el Red Hat Security Advisory, se trata de una falla causada por una condición de carrera durante el manejo de enlaces simbólicos en rsync
    • El comportamiento predeterminado de rsync es omitir los enlaces simbólicos cuando los encuentra, pero un atacante podía esquivar ese comportamiento cambiando un archivo normal por un enlace simbólico en el momento adecuado, logrando que se recorriera el enlace simbólico

  • la corrección upstream cambió la llamada open() del sender de rsync para usar la opción O_NOFOLLOW

    • gokrazy/rsync fue vulnerable hasta el commit 1b1fbf6, que introdujo la misma mitigación O_NOFOLLOW que rsync upstream
    • Damien Neil consideró que la corrección de gokrazy para CVE-2024-12747 era insuficiente, y concluyó que O_NOFOLLOW solo impide seguir enlaces simbólicos en el último componente de la ruta
    • por ejemplo, en os.Open("dir/passwd"), si se cambia el componente anterior de la ruta, dir, por un enlace simbólico que apunte a /etc, todavía es posible eludir la protección
    • este problema fue reportado al contacto de seguridad de rsync en abril de 2025 y derivó en el CVE-2026-29518, publicado el 2026-05-20

Vulnerabilidades de mayo de 2026

  • CVE-2026-29518: condición de carrera con enlaces simbólicos, gravedad 7.0

    • Según la entrada de NEWS de rsync 3.4.3, se trata de una condición de carrera TOCTOU con enlaces simbólicos que permite elevación local de privilegios en modo daemon sin chroot
    • Un daemon de rsync configurado con use chroot = no queda expuesto a una carrera de time-of-check/time-of-use sobre componentes de ruta padre
    • Un atacante local con acceso de escritura al módulo puede reemplazar un componente del directorio padre por un enlace simbólico entre la verificación del receiver y open(), provocando divulgación del basis-file en lecturas y sobrescritura de archivos fuera del módulo en escrituras
    • La configuración predeterminada, use chroot = yes, no está expuesta
    • La corrección upstream usa secure_relative_open(), similar a la API os.Root de Go
    • gokrazy/rsync fue vulnerable hasta que cambió tanto el sender como el receiver a la API os.Root, resistente a traversal

  • CVE-2026-43618: filtración remota de memoria por desbordamiento de enteros, gravedad 8.1

    • El decodificador de tokens comprimidos del receptor de rsync acumula un contador con signo de 32 bits sin verificar desbordamiento, lo que permite que un emisor malicioso filtre contenido de la memoria del proceso
    • Lo filtrado puede incluir variables de entorno, contraseñas y punteros del heap y de bibliotecas, debilitando ASLR y facilitando exploits adicionales
    • El alcance se limita a conexiones autenticadas al daemon con compresión activada, que se habilita por defecto en el protocolo 30 o superior si ambos peers anuncian compresión
    • La mitigación es desactivar la compresión del daemon con refuse options = compress en rsyncd.conf
    • La corrección upstream agrega la verificación faltante
    • gokrazy/rsync no es vulnerable porque no implementa compresión, y aunque el soporte para compresión parece simple, las razones por las que no lo es están resumidas en gokrazy/rsync issue #35

  • CVE-2026-43620: denegación de servicio tras lectura fuera de rango, gravedad 6.5

    • Ocurre porque la protección parent_ndx<0 agregada a send_files() en 2025 no se aplicó al bloque visualmente idéntico de recv_files()
    • Si un servidor rsync malicioso envía la bandera de compatibilidad CF_INC_RECURSE y una flist malformada, el receptor puede leer y desreferenciar dir_flist->files[-1], lo que lleva a un SIGSEGV determinista
    • Afecta a cualquier cliente rsync que haga un pull normal desde una URL controlada por un atacante, sin requerir opciones especiales del lado de la víctima debido a inc_recurse, que es el valor predeterminado en el protocolo 30 o superior
    • La mitigación en el cliente es usar --no-inc-recursive, y la corrección upstream agrega también la protección parent_ndx<0 a recv_files()
    • gokrazy/rsync no se ve afectado porque no implementa el modo recursivo incremental --inc-recursive, al igual que con CVE-2024-12087

  • CVE-2026-43619: condición de carrera adicional con enlaces simbólicos, gravedad 6.3

    • La corrección de la condición de carrera con enlaces simbólicos en las llamadas open() del receptor (CVE-2026-29518) no se aplicó a otras llamadas al sistema basadas en rutas como chmod, lchown, utimes, rename, unlink, mkdir, symlink, mknod, link, rmdir y lstat
    • En daemons de rsync configurados con use chroot = no, un atacante local puede reemplazar un componente del directorio padre por un enlace simbólico entre la verificación del receptor y la llamada al sistema para redirigir la operación fuera del módulo exportado
    • La configuración predeterminada, use chroot = yes, no está expuesta
    • La corrección upstream maneja las llamadas al sistema basadas en rutas afectadas a través de un dirfd padre abierto bajo restricciones impuestas por el kernel, como openat2 en Linux 5.6+, O_RESOLVE_BENEATH en FreeBSD 13+ y macOS 15+, o recorrido componente por componente con O_NOFOLLOW en otros entornos
    • gokrazy/rsync no se ve afectado porque usa de forma general la API os.Root de Go

  • CVE-2026-43617: bypass de ACL basado en hostname, gravedad 4.8

    • En daemons de rsync con la configuración global daemon chroot = /X en rsyncd.conf, la búsqueda DNS inversa del cliente que se conecta se realizaba después de que el daemon hiciera chroot a /X
    • Si en /X faltan /etc/resolv.conf, /etc/nsswitch.conf, /etc/hosts y los módulos del servicio NSS necesarios para la resolución de glibc, la consulta falla y el hostname de origen queda establecido como "UNKNOWN"
    • Como las reglas deny basadas en hostname como hosts deny = *.evil.example no hacen match, un atacante que controle el registro PTR puede conectarse desde un hostname que el administrador intentaba bloquear
    • Las ACL basadas en IP no se ven afectadas, y la configuración use chroot por módulo no está relacionada con esta vulnerabilidad
    • La corrección upstream mueve la consulta DNS a una etapa más temprana del protocolo
    • gokrazy/rsync no es vulnerable porque no implementa listas allow/deny basadas en hostname y solo implementa listas allow/deny basadas en IP

  • CVE-2026-45232: escritura fuera de rango en la pila, gravedad 3.1

    • El soporte de proxy HTTP CONNECT del cliente rsync tiene una escritura off-by-one fuera de rango en la pila en establish_proxy_connection()
    • Si un proxy o un atacante man-in-the-middle devuelve 1023 bytes o más sin '\n' en la primera línea de respuesta, el código posterior puede escribir '\0' justo después del búfer de 1024 bytes y corromper una posición adyacente de la pila
    • AddressSanitizer reporta stack-buffer-overflow en socket.c:95 dentro del frame de establish_proxy_connection
    • La corrección upstream valida los datos proporcionados por el atacante
    • gokrazy/rsync no es vulnerable porque no implementa este soporte de proxy

Lo que Go y gokrazy/rsync realmente bloquearon

  • La verificación de límites del runtime de Go convierte problemas de seguridad más graves en panic; aunque un panic sigue siendo un riesgo de denegación de servicio, se considera un mejor modo de falla
  • Go inicializa la memoria en cero, lo que hace imposible una filtración de información como CVE-2024-12085
  • La API os.Root de Go previene la mayoría de las vulnerabilidades restantes
  • De las 12 vulnerabilidades, solo CVE-2026-43617 se clasifica como un bug de lógica de aplicación que no puede evitarse usando Go
  • La diferencia principal entre gokrazy/rsync y el rsync upstream oficial, además de estar escrito en Go, es que su implementación está minimizada
  • Como gokrazy/rsync no implementa varias funciones problemáticas como --inc-recursive, --safe-links, compresión, proxy o ACL por nombre de host, evita varias vulnerabilidades
  • Como toda implementación de rsync compatible con el protocolo wire, gokrazy/rsync apunta a la versión 27 del protocolo, y las versiones posteriores introducen una complejidad considerable
  • Estado de gokrazy/rsync por CVE al momento de la publicación:
    • 2024-12084: estaba implementado y provocaba panic
    • 2024-12085: no era vulnerable porque es una función del protocolo 30 y no estaba implementada
    • 2024-12086: no era vulnerable porque es una función del protocolo 29 y no estaba implementada
    • 2024-12087: no era vulnerable porque no implementa inc-rec
    • 2024-12088: no era vulnerable porque no implementa safe-links
    • 2024-12747: estaba implementado y era vulnerable
    • 2026-29518: estaba implementado y fue corregido
    • 2026-43617: no era vulnerable porque no implementa la lista de hosts denegados
    • 2026-43618: no era vulnerable porque no implementa compresión
    • 2026-43619: estaba implementado y fue corregido
    • 2026-43620: no era vulnerable porque no implementa inc-rec
    • 2026-45232: no era vulnerable porque no implementa proxy
  • Todas las vulnerabilidades conocidas de gokrazy/rsync ya fueron corregidas, y el estado anterior refleja la situación en el momento en que se publicó cada CVE
  • Cuando se divulgaron las vulnerabilidades en enero de 2025, gokrazy/rsync provocaba panic en CVE-2024-12084 y era vulnerable a la condición de carrera TOCTOU de CVE-2024-12747
  • Durante el proceso de corrección del problema TOCTOU se descubrió CVE-2026-29518, y se corrigió en gokrazy/rsync antes de que ese CVE se hiciera público
  • CVE-2026-43619 se descubrió más tarde, pero en gokrazy/rsync ya estaba resuelto mediante la misma corrección: uso total de os.Root de Go

Distinción de roles y denominación de vulnerabilidades

  • Varios reportes de vulnerabilidades usaban las expresiones “server” y “client”, pero en una transferencia rsync tanto el cliente rsync como el servidor pueden asumir el rol de emisor (sender, carga de archivos) o receptor (receiver, descarga de archivos)
  • En modo daemon, el acceso al sistema de archivos puede limitarse a una ruta de módulo configurada de antemano, pero en command mode no es así
  • Las 4 configuraciones y las capas de rol/protocolo pueden verse en el diagrama rsync combinations
  • El título original de la vulnerabilidad Arbitrary File Leak (CVE-2024-12086), “Server leaks arbitrary client files”, puede prestarse a confusión
  • Una descripción más precisa es que el receptor rsync filtra archivos arbitrarios a un emisor malicioso
  • Un cliente emisor malicioso puede hacer que un rsync remoto sin parchear, en entornos como command mode sobre SSH, abra archivos fuera del árbol de destino, por ejemplo la base de datos de contraseñas del sistema /etc/shadow
  • En modo daemon, el servidor activa una sanitización adicional de rutas (path sanitization) para bloquear este ataque
  • La vulnerabilidad Symlink Path Traversal (CVE-2024-12087) también se describe como “malicious server”, pero en realidad se trata de un emisor malicioso, que puede ser tanto cliente como servidor

Comparación con OpenBSD openrsync

  • El proyecto OpenBSD es conocido por su enfoque en seguridad, y openrsync valida la longitud del checksum y solo soporta MD4 como tamaño/algoritmo de checksum, por lo que no se ve afectado por Heap Buffer Overflow (CVE-2024-12084) ni Stack Info Leak (CVE-2024-12085)
  • Igual que gokrazy/rsync, openrsync no se ve afectado por CVE-2024-12086, CVE-2024-12087 y CVE-2024-12088 porque no implementa las funciones relacionadas
  • Incluso si hubiera sido vulnerable, al ejecutarse en OpenBSD la defensa en profundidad de OpenBSD unveil(2) y pledge(2), que limitan el acceso al sistema de archivos, podría haber impedido una explotación exitosa
  • openrsync no se ve afectado por CVE-2024-12747 porque usa O_NOFOLLOW`` desde el momento en que implementó soporte para enlaces simbólicos
  • Sin embargo, O_NOFOLLOW no es una corrección suficiente para este problema, por lo que openrsync sí se ve afectado por CVE-2026-29518
  • El paquete de mayo de 2026 también es similar en que la mayoría de las funciones relacionadas no estaban implementadas
  • openrsync no se ve afectado por la mayoría de las vulnerabilidades reportadas porque implementa la validación de forma rigurosa, limita la superficie de ataque y aplica defensa en profundidad

Defensa en profundidad y os.Root

  • Linux mount namespace

    • A las pocas semanas de iniciar el proyecto gokrazy/rsync, se agregó soporte en Linux para bajar privilegios y usar los namespaces de mount/pid con el fin de restringir el acceso a objetos del sistema de archivos
    • Este enfoque funciona bien para mitigar ataques de path traversal, pero requiere privilegios, por lo que debe ejecutarse como root o dentro de un Linux user namespace si está habilitado en la distribución o el sistema
    • El mount namespace es adecuado para configuraciones de servidor, pero muchas veces no puede usarse en transferencias interactivas de una sola vez que se ejecutan desde la cuenta de un usuario común

  • Endurecimiento con systemd

    • El mismo commit que introdujo el soporte para Linux mount/pid namespace también incluyó un archivo de servicio de systemd que limita el acceso al sistema de archivos al directorio home, y en el README se recomienda restringir aún más el acceso al sistema de archivos según el caso de uso
    • Si estas restricciones del sistema de archivos se configuran correctamente, mitigan las vulnerabilidades File Leak (CVE-2024-12086) y Path Traversal (CVE-2024-12087)
    • Symlink Race Condition (CVE-2024-12747) depende de una escalada de privilegios a través del proceso de rsync, pero gracias a la función DynamicUser, el proceso tiene menos privilegios que otros usuarios
    • Al igual que mount namespace, es bueno para configuraciones de servidor, pero resulta engorroso de configurar para usos interactivos de una sola vez

  • Linux Landlock

    • Porting OpenBSD pledge() to Linux (2022) recordó que Linux también tiene el Landlock API, un control de acceso no privilegiado y por proceso similar a unveil(2) de OpenBSD
    • La idea básica es que, una vez que el programa sabe en qué directorio va a trabajar, una llamada como unveil("/home/michael/backups", "rw"); impide que vuelva a acceder a ubicaciones del sistema de archivos fuera de esa ruta
    • En marzo de 2025 se implementó soporte para Landlock para restringir el acceso al sistema de archivos
    • Una vez ajustada la configuración, incluso en ejecuciones sin privilegios de gokrazy/rsync se puede limitar la transferencia de rsync a solo lectura en el origen y lectura-escritura en el directorio de destino
    • La desventaja es que Landlock opera a nivel de proceso
    • La política de Landlock también debe incluir los archivos que necesita el programa; por ejemplo, gokrazy/rsync debe poder leer /etc/passwd para consultar IDs de usuario, así que si un atacante apunta a /etc/passwd, Landlock no ayuda

  • os.Root de Go

    • En febrero de 2025, Go 1.24 introdujo la API os.Root, resistente a path traversal, y el contexto relacionado está resumido en The Go Blog: Traversal-resistant file APIs de Damien Neil
    • En comparación con Landlock, os.Root ofrece un control más fino por operación del sistema de archivos
    • Go 1.25, lanzado en agosto de 2025, agregó más métodos a os.Root, convirtiéndolo en una opción práctica para la mayoría de los usos del sistema de archivos
    • Todo el uso del sistema de archivos en gokrazy/rsync se migró a os.Root, lo que encaja bien con el modelo en el que el usuario configura los directorios de entrada y salida, pero los nombres de archivo recibidos por red no son confiables
    • Incluso llamadas al sistema como mknod(2), que parecerían imposibles de crear directamente con la API, pueden usarse de forma segura
    • Damien Neil explica que se puede abrir el directorio padre del destino con os.Root.OpenFile, obtener el file descriptor de ese directorio con File.Fd y luego crear el archivo con golang.org/x/sys/unix#Mknodat
    • Un ejemplo de uso real está en internal/receiver/generatormknod_linux.go, line 15-29
    • Linux tiene mknodat(2), pero hasta Linux 7.0 no existe un bindat equivalente a bind(2)
    • Lennart Poettering propuso que, sin bindat, se puede hacer bind a /proc/self/<fd>/foobar como truco para omitir la resolución de rutas
    • Si después de un /proc/self/<fd> seguro y conocido se especifica no una ruta sino un basename, es decir, solo el último componente de la ruta, se omite la resolución de rutas; el código relacionado está en line 49-56
    • Gracias a estos dos consejos, gokrazy/rsync v0.3.1 y posteriores usan os.Root por completo, y todo acceso al sistema de archivos tiene seguridad frente a path traversal

Lecciones clave

  • Todas las vulnerabilidades, excepto las vulnerabilidades TOCTOU (CVE-2024-12747, CVE-2026-29518, CVE-2026-43619), provienen de falta de validación de entrada o de validación incorrecta de entrada
  • En tres casos no había validación desde el principio, y en CVE-2024-12088 el tema de la resolución de rutas del sistema de archivos es tan complicado que la validación existente no cubría todos los casos límite
  • La corrección estructural más valiosa es ofrecer validaciones siempre activas, como las comprobaciones de límites, y APIs seguras por defecto como os.Root de Go
  • Algunas vulnerabilidades surgieron por la evolución del protocolo rsync: se agregaron nuevas funciones a código que originalmente sí validaba lo suficiente, pero la validación no se actualizó correctamente
  • La negociación del algoritmo de checksum y la recursión incremental se agregaron en la versión 30 del protocolo, y la validación existente no se actualizó para ajustarse a la forma en que se procesaban las nuevas funciones
  • gokrazy/rsync y openrsync no eran vulnerables a 8 de las 12 vulnerabilidades de seguridad simplemente porque no implementaban las funciones vulnerables
  • Esas funciones se agregaron a rsync porque en algún momento tuvieron valor para alguien, y eso no significa que se deba dejar de desarrollar software
  • La elección ideal es usar una implementación cuya complejidad sea adecuada y proporcional a la complejidad del caso de uso: elegir implementaciones simples para casos de uso simples y recurrir a implementaciones con todas las funciones solo cuando sea necesario

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Comentarios de Lobste.rs
  • Excelente artículo. Es tan bueno que todos los lenguajes deberían incluir en su biblioteca estándar una API como os.Root
    Después de pasar por algunas vulnerabilidades de path traversal en SecureDrop, usamos una versión muy simplificada, y ahora, usando la API correcta, una clase completa de vulnerabilidades desaparece
    • Sí. Parece que el verdadero protagonista de esta entrada del blog no es Go, sino os.Root