Lanzan la primera versión estable de sudo-rs, una implementación de sudo con seguridad de memoria

 (memorysafety.org)
1 puntos por GN⁺ 2023-11-07 | 1 comentarios | Compartir por WhatsApp
  • sudo-rs, una nueva implementación en Rust de sudo usada para cambiar límites de privilegios, fue publicada en su primera versión estable
  • Se estima que cerca de un tercio de los bugs de seguridad del sudo original estaban relacionados con problemas de gestión de memoria, y ese fue el motivo principal detrás de la reescritura en Rust
  • sudo-rs reduce la superficie de ataque al excluir funciones menos utilizadas, y su suite de pruebas también sirvió para encontrar bugs en el sudo original
  • Wolfi Linux OS ya incluye sudo-rs, y Chainguard considera que mejorar herramientas de seguridad críticas puede influir en toda la industria
  • Está previsto que una auditoría de seguridad externa comience en septiembre de 2023, y después el trabajo avanzará hacia el Milestone 4, centrado en funciones empresariales

sudo-rs reimplementado en Rust

  • Prossimo publicó la primera versión estable de sudo-rs
  • sudo-rs es un proyecto que reimplementa en Rust la utilidad sudo, usada comúnmente en Linux para cruzar el límite de privilegios entre una cuenta de usuario y una cuenta de administrador
  • El proyecto sudo-rs está enfocado en mejorar la seguridad frente al sudo original
    • Usa Rust para garantizar seguridad de memoria
    • El punto de partida fue la estimación de que cerca de un tercio de los bugs de seguridad del sudo original se debían a problemas de gestión de memoria
    • Reduce la superficie de ataque al excluir funciones menos comunes
    • Se desarrolló una amplia suite de pruebas, y estas pruebas también encontraron bugs en el sudo original

Adopción y próximos pasos

  • Wolfi Linux OS ya incluye sudo-rs
  • Dan Lorenc, CEO y cofundador de Chainguard, considera que la seguridad de memoria fue la máxima prioridad al crear Wolfi, y que mejorar una herramienta de seguridad crítica como sudo puede tener un gran impacto en toda la industria
  • sudo-rs fue desarrollado por un equipo conjunto de Tweede Golf y Ferrous Systems bajo contrato con Prossimo
  • El proyecto comenzó en diciembre de 2022, y está previsto que una auditoría de seguridad externa del código de sudo-rs comience en septiembre de 2023
  • Después de la auditoría, el equipo pasará al Milestone 4 del plan de trabajo, una etapa enfocada en funciones empresariales
  • La utilidad sudo original basada en C ha sido mantenida durante mucho tiempo por Todd C. Miller, quien también aportó asesoría para la implementación de sudo-rs
  • NLnet Foundation financió la auditoría de sudo-rs, y Amazon Web Services apoya este trabajo y la transición hacia software con seguridad de memoria

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-11-07
Opiniones de Hacker News

  • Como uno de los desarrolladores originales de sudo (https://en.wikipedia.org/wiki/Sudo), he visto durante los últimos 43 años cómo se ha reescrito casi por completo y se le han corregido errores continuamente.
    Podría decirse que, entre los comandos de UNIX, es el que más revisión ha recibido por fallas de seguridad, y las fallas encontradas se han ido corrigiendo.
    Me pregunto si es posible que un solo equipo de desarrollo reimplemente por completo una herramienta que han revisado miles de desarrolladores y expertos en seguridad sin introducir ni uno o dos bugs nuevos.
    Me pregunto si el lenguaje Rust tiene algo que elimine mágicamente toda posibilidad de introducir bugs.

    • No puedo sino agradecer el trabajo de quienes crearon sudo, y creo que es una herramienta realmente valiosa en el uso diario de mucha gente.
      Desde el lado de quienes hacemos sudo-rs, nunca hemos intentado invalidar el trabajo existente, y somos muy conscientes de que, sobre todo al principio, nuestra implementación no estará libre de bugs.
      En lo personal, al crear una versión en Rust pude abordar áreas que normalmente me habría costado tocar, porque no tengo mucha confianza en poder escribir código C relativamente seguro.
      Como mínimo, gracias a este trabajo ya encontramos algunos bugs en el sudo existente, y aunque se haya venido corrigiendo durante 43 años, mientras cambie el entorno que lo rodea es difícil que un software así llegue a estar completamente libre de bugs.
      Mientras colaboremos y aprendamos del trabajo y los errores de los demás, no tiene nada de malo que haya algunas alternativas.
    • Más allá de lo que haya pasado durante los últimos 43 años, en 2021 hubo una vulnerabilidad de corrupción de memoria ampliamente explotable llamada Baron Samedit.
    • Los sistemas de tipos avanzados, el borrow checker y los lenguajes con seguridad de memoria sin duda ayudan mucho, pero por supuesto no eliminan todos los bugs.
      Al hacer RiiR, lo mejor que puede hacer un desarrollador es seguir buenas prácticas y aprender de errores pasados.
      En 43 años se ha avanzado mucho, y solo con abandonar el manejo de cadenas de C se eliminan innumerables bugs incluso antes de hablar de seguridad de memoria.
      Hoy, quien quiera crear un reemplazo seguro de sudo podría hacerlo mucho mejor que antes incluso usando solo C, y el proyecto OpenBSD lo demuestra bastante bien.
      Si a nivel de lenguaje se eliminan muchas de las aristas peligrosas que el código de OpenBSD evita, se parte con ventaja, pero aun así se necesita mucha atención y experiencia, y un lenguaje de programación no puede reemplazar eso.
      Como mínimo vale la pena revisarlo seriamente, aunque me parece que por ahora no debería distribuirse como opción predeterminada.
    • No quiero negar la experiencia, y espero que este proyecto sin duda redescubra dolores ya conocidos, pero también es importante señalar que no necesitamos repetir tal cual el trabajo de toda la vida de Newton, Leibniz y Maxwell para entender bien la física clásica.
      Hoy eso está en el plan de estudios de secundaria; si lo apruebas puedes desempeñarte bastante bien, y con un poco más de esfuerzo puedes manejar muy bien aquello que a ellos les llevó toda una vida.
      Esto se debe a que podemos pararnos sobre hombros de gigantes, contamos con retrospectiva y mejores tecnologías y métodos de aprendizaje, y no necesitamos repetir todos sus errores.
      Si el desarrollador original reescribiera sudo desde cero hoy, con su experiencia y conocimientos actuales, probablemente lo haría en mucho menos tiempo y de forma más limpia y simple.
      No se trata de menospreciar el esfuerzo y la experiencia existentes, sino de decir que no es imposible convertir esa experiencia en algo mejor en menos tiempo.
    • En cuanto a seguridad de memoria, sí; y un lenguaje que sea seguro por defecto es mucho mejor, pero no hace nada contra los bugs lógicos.
      Aun así, al reemplazar sudo u otras herramientas escritas en C, vulnerabilidades como punteros nulos o mal uso de buffers fácilmente representan el 50% del total.

  • Creo que los dos puntos que destaca este proyecto suelen pasarse por alto incluso más que el uso de Rust.
    Reducir la superficie de ataque eliminando funciones poco usadas, y desarrollar un conjunto amplio de pruebas que incluso ha encontrado bugs en el sudo existente.
    Al escribir código crítico para la seguridad, estos aspectos son incluso más importantes que reescribirlo en Rust.

  • Suponiendo que el objetivo de este proyecto sea reemplazar a sudo, me preocupa un poco pasar por alto lo de “excluir funciones menos usadas”
    Importa cuáles son esas funciones, qué tan poco se usan y de qué manera falla en configuraciones que las usan
    Edición: parece que algunas limitaciones están resumidas en el README de GitHub, https://github.com/memorysafety/sudo-rs#differences-from-ori...

    • Una de las funciones que faltan es sudoedit o sudo -e
      Se usa mucho para editar archivos dentro de /etc o archivos para los que mi usuario no tiene permisos; esta bandera primero copia el archivo a una ubicación temporal donde mi usuario pueda editarlo, y luego ejecuta el editor de texto con los permisos de mi usuario, sin privilegios de sudo
      El editor se define con la variable de entorno $SUDO_EDITOR y, después de cerrarlo, solo si hubo cambios vuelve a copiar el archivo con los permisos originales
      Lo bueno es que ejecuta el editor como mi usuario, no como root, así que carga mi configuración y mis plugins de usuario
    • Una de las funciones que no aparece como faltante es la de ejecutar make me a sandwich (https://github.com/sudo-project/sudo/blob/main/Makefile.in#L...)
    • Una función que se usa en entornos más grandes, pero que no está en la hoja de ruta de sudo-rs ni está implementada, es el soporte para LDAP
      En el sudo normal se pueden administrar los privilegios de sudo de toda la red desde una configuración LDAP central, y también crear de forma centralizada reglas limitadas por tiempo, host, usuario y comando
      Sin la posibilidad de que un simple error de sintaxis arruine toda la configuración; en ese caso, simplemente se ignora esa regla
    • Ya vivimos la transición a systemd, así que los administradores de sistemas podrán manejar algo de este nivel
      Seguramente habrá muy buena documentación técnica, y esto es un lanzamiento promocional, así que no creo que sea el lugar para buscar una lista de funciones faltantes
    • Que una de las herramientas UNIX más básicas tenga tantas funciones incorporadas es, en sí mismo, una señal de alarma mucho mayor

  • Al ver la diferencia entre Apache-2.0+MIT y GPL-2.0, se puede obtener un su/sudo-rs con seguridad de memoria, pero quien lo distribuya en forma binaria no tiene la obligación de publicar el código fuente usado para compilarlo ni posibles modificaciones

    • Yo también quería escribir este comentario
      Me preocupa mucho que la tendencia a desplazar herramientas GPL con reescrituras en Rust bajo licencias MIT/Apache algún día termine llevando a un Linux propietario, pero sudo originalmente no es GPL
      Es una licencia estilo ISC/MIT [1]
      1. https://www.sudo.ws/about/license/
    • Alejarse de la GPL en componentes centrales como este es una muy mala idea
      Justamente por el motivo mencionado arriba, y lo dejo para subrayar ese problema
    • Sudo no es GPL, sino que usa una licencia muy permisiva de la familia ISC[0]
      su sí parece ser GPL
      [0]: https://www.sudo.ws/about/license/
    • ¿Eso es realmente malo?
      Tienes la libertad de no usar una distribución así
      Desde el punto de vista de la seguridad, un actor malicioso también podría mostrar un código fuente distinto del binario que distribuye
      Lo mismo da si es GPL o no
    • Para bien o para mal, el uso de la GPL está disminuyendo, y el futuro del kernel Linux tampoco está garantizado
      En el ámbito de los sistemas operativos libres y de código abierto tipo UNIX para IoT, todos los candidatos, incluido ZephyrOS patrocinado por la Linux Foundation, usan una mezcla de licencias Apache, MIT y BSD
      Cuando desaparezca la generación GPL, no tardará en surgir un sistema operativo tipo UNIX con una licencia más atractiva para las grandes empresas como otra alternativa de entidad mantenedora del kernel Linux

  • Sería interesante ver una derivada de Debian que combine esto con GNU Coreutils implementado en Rust
    Podría traer grandes beneficios en seguridad de memoria y rendimiento
    [1] https://github.com/uutils/coreutils

    • Me pregunto cuánto falta para tener un espacio de usuario UNIX basado en Rust
      Al menos no hará falta implementar un compilador de C

  • ¿Es como sacarle brillo a una mierda?
    Claro que una mejor reimplementación está bien, pero ¿no les sorprendió leer las funciones raras de sudo?
    Incluso las partes que parecen normales son muy extrañas y sutiles, y por eso son vulnerables
    Quien use sudo “a fondo” haría bien en pensar si hay otra forma

  • Estaría bueno tener una bandera o herramienta de validación/verificación que haga una prueba con la configuración actual de sudo y muestre qué partes no soporta sudo-rs
    En proyectos así hace falta un asistente de portabilidad para que la transición sea fluida

  • Si no recuerdo mal, las vulnerabilidades recientes de sudo fueron todas errores de lógica, no problemas de seguridad de memoria
    Reescribirlo está bien, pero no hay que fingir que no pueden introducirse nuevos bugs por malentender cómo funciona algo o por un simple error común

    • 2021: https://nvd.nist.gov/vuln/detail/CVE-2021-3156
      2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634
    • ¿Quién está fingiendo eso?
      Veo muchas afirmaciones sobre seguridad de memoria, pero no parece que este proyecto diga que otros tipos de bugs queden eliminados con certeza
    • Del mismo modo, al sudo existente también se le pueden introducir nuevos bugs de memoria
      Reducir la superficie de ataque mediante comprobaciones estáticas parece una mejor apuesta a largo plazo

  • doas es una herramienta mucho más simple que hace lo mismo
    No entiendo muy bien por qué no se usa más

  • doas ocupa 43184 bytes y hace todo lo que necesito
    Ese exploit de sudo fue una llamada de atención
    Si todavía no te has cambiado, vale la pena probar opendoas (paquete de Debian)