Se ha detectado una vulnerabilidad crítica en el repositorio de paquetes RubyGems.org (CVE-2022-29176) que permite alterar algunos paquetes ajenos en el repositorio sin los permisos adecuados, iniciando la retirada (yank) de un paquete legítimo y subiendo en su lugar otro archivo con el mismo nombre y número de versión.
Para explotar con éxito la vulnerabilidad, es necesario cumplir tres condiciones:
- El ataque solo puede dirigirse a paquetes cuyo nombre contenga el símbolo de guion.
- El atacante debe poder publicar un paquete gem con una parte del nombre antes del guion. Por ejemplo, si el ataque se realiza sobre el paquete «rails-html-sanitizer», el atacante debería publicar en el repositorio su propio paquete «rails-html».
- El paquete que se ataca debe haber sido creado en los últimos 30 días o no haber sido actualizado en los últimos 100 días.
La vulnerabilidad es causada por un error en el manejador de la acción «yank», que interpreta la parte del nombre después del guion como el nombre de la plataforma, lo que permitía iniciar la eliminación de paquetes ajenos que coincidieran en la parte del nombre antes del guion. En particular, en el código del manejador de la operación «yank», se utilizó la llamada ‘find_by!(full_name: «#{rubygem.name}-#{slug}»)’ para buscar paquetes, siendo que el parámetro «slug» era proporcionado por el propietario del paquete para determinar la versión a eliminar. El propietario del paquete «rails-html» podría haber indicado «sanitizer-1.2.3» en lugar de la versión «1.2.3», lo que habría llevado a aplicar la operación al paquete ajeno «rails-html-sanitizer-1.2.3».
El problema fue detectado por un investigador de seguridad dentro del programa de recompensas por encontrar problemas de seguridad en proyectos de código abierto conocido en HackerOne. El problema fue solucionado en RubyGems.org el 5 de mayo y, según los desarrolladores, no han encontrado evidencia de explotación de la vulnerabilidad en los registros de los últimos 18 meses. Hasta ahora solo se ha realizado una auditoría superficial y se planea llevar a cabo una revisión más exhaustiva en el futuro.
Para verificar tus proyectos, se recomienda analizar el historial de operaciones en el archivo Gemfile.lock; la actividad maliciosa se manifiesta en la existencia de cambios que mantienen el nombre y la versión o cambian la plataforma (por ejemplo, cuando el paquete gemname-1.2.3 se actualiza a gemname-1.2.3-java). Como método de protección contra la suplantación oculta de paquetes en sistemas de integración continua o al publicar proyectos, se recomienda a los desarrolladores utilizar Bundler con las opciones "—frozen" o "—deployment" para fijar dependencias.
Fuente: opennet.ru
