Google revela una falla de seguridad en GitHub
Project Zero dio a conocer detalles de una grave brecha de seguridad en GitHub e informan que el error afecta los comandos de flujo de trabajo de acciones de GitHub y se describe como de gravedad alta. (Este error fue descubierto en julio, pero, según el período de divulgación estándar de 90 días, los detalles solo se han hecho públicos ahora).
Esta falla se convirtió en una de las pocas vulnerabilidades que no se corrigió adecuadamente antes de que expirara el plazo estándar de 90 días otorgado por Google Project Zero.
Según Felix Wilhelm (quien lo descubrió), el miembro del equipo de Project Zero, la falla afecta la función acciones de GitHub, una herramienta para automatizar el trabajo de los desarrolladores. Esto se debe a que los comandos de flujo de trabajo de Actions son “vulnerables a los ataques de inyección”:
“Actions Github admite una función llamada comandos de flujo de trabajo como canal de comunicación entre el corredor de Action y la acción ejecutada. Los comandos de flujo de trabajo se implementan encorredor / src / Runner.Worker / ActionCommandManager.csy funciona analizando STDOUT de todas las acciones realizadas buscando uno de los dos marcadores de comando.
Menciona que el gran problema con esta función es que es muy vulnerable a los ataques de inyección. Debido a que el proceso de ejecución escanea cada fila impresa en STDOUT en busca de comandos de flujo de trabajo, cada acción de GitHub que contiene contenido no confiable como parte de su ejecución es vulnerable.
En la mayoría de los casos, la capacidad de establecer variables de entorno arbitrarias da como resultado la ejecución remota de código tan pronto como se ejecuta otro flujo de trabajo. He pasado algún tiempo mirando repositorios populares de GitHub y casi cualquier proyecto que use acciones de GitHub ligeramente complejas es vulnerable a esta clase de error.
Posteriormente, dio algunos ejemplos de cómo se podría aprovechar el error y también sugirió una solución:
“Realmente no estoy seguro de cuál es la mejor manera de solucionarlo. Creo que la forma en que se implementan los comandos de flujo de trabajo es fundamentalmente insegura. Depreciar la sintaxis del comando v1 y fortalecerset-envcon una lista de permitidos probablemente funcionaría contra los vectores RCE directos.
“Sin embargo, incluso la capacidad de anular las variables de entorno ‘normales’ utilizadas en los pasos posteriores probablemente sea suficiente para explotar las acciones más complejas. Tampoco he analizado el impacto de seguridad de los otros controles en el espacio de trabajo.
Por otra parte, menciona que una buena solución a largo plazo sería mover los comandos del flujo de trabajo a un canal independiente (por ejemplo, un nuevo descriptor de archivo) para evitar el análisis de STDOUT, pero esto romperá una gran cantidad de código de acción existente.
En cuanto a GitHub, sus desarrolladores publicaron un aviso el 1 de octubre y depreció los comandos vulnerables, pero argumentó que lo que Wilhelm encontró era de hecho una «vulnerabilidad de seguridad moderada». GitHub asignó al error el identificador CVE-2020-15228:
«Se ha identificado una vulnerabilidad de seguridad moderada en el tiempo de ejecución de Acciones de GitHub que puede permitir la inyección de rutas y variables de entorno en los flujos de trabajo que registran datos que no son de confianza en STDOUT. Esto puede llevar a la introducción o modificación de variables de entorno sin la intención del autor del flujo de trabajo.
“Para ayudarnos a resolver este problema y permitirle establecer dinámicamente las variables de entorno, hemos introducido un nuevo conjunto de archivos para manejar las actualizaciones de entorno y rutas en los flujos de trabajo.
“Si utiliza corredores autohospedados, asegúrese de que estén actualizados a la versión 2.273.1 o superior.
Según Wilhelm, el 12 de octubre, Project Zero se puso en contacto con GitHub y les ofreció de forma proactiva un plazo de 14 días si GitHub quería más tiempo para desactivar los comandos vulnerables. Por supuesto, la oferta fue aceptada y GitHub esperaba desactivar los comandos vulnerables después del 19 de octubre. Project Zero luego estableció la nueva fecha de divulgación para el 2 de noviembre.
Fuente: https://bugs.chromium.org