El equipo de Google Project Zero es conocido por descubrir vulnerabilidades y errores en el propio software de Google. Aunque es más conocido por desvelar fallos de seguridad de otras empresas. Su metodología implica identificar los defectos de seguridad en el software y reportarlos de forma privada a los proveedores, dándoles 90 días para arreglarlos antes de la divulgación pública.

Dependiendo de la complejidad de la corrección requerida, a veces también ofrece días adicionales en forma de un período de gracia. En escenarios específicos, las empresas pueden incluso recibir menos de los 90 días estándar para solucionar problemas antes de que Google los anuncie públicamente.

GitHub tendrá que corregir un grave problema de seguridad

En los últimos dos años, el equipo ha revelado vulnerabilidades importantes en Windows, Windows 10 S, kernel macOS e iOS, entre otros. Hace un par de días, el equipo de seguridad reveló un exploit presente en varias versiones de Windows, y hoy ha revelado un fallo de seguridad en GitHub.

La vulnerabilidad ha sido clasificada como un problema de «alta gravedad» por Google Project Zero. Os ahorraremos los detalles técnicos, aunque podéis leerlos aquí si queréis. Pero, el problema radica en los comandos de flujo de trabajo de las acciones de GitHub. Estos son extremadamente vulnerables a los ataques de inyección. Para aquellos que no son conscientes, los comandos de flujo de trabajo actúan como un canal de comunicación entre las acciones ejecutadas y el ejecutor de acciones. Felix Wilhelm, que descubrió el fallo de seguridad a través de la revisión del código fuente, dice que:

El gran problema con esta característica es que es altamente vulnerable a los ataques de inyección. Como el
el proceso analiza todas las líneas impresas en STDOUT en busca de comandos de flujo de trabajo. Cada acción de Github que imprime contenido que no es de confianza 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.

En su post original, Wilhelm continuó diciendo que no está seguro de cómo solucionar el problema. La forma en que se implementan los comandos de flujo de trabajo es «fundamentalmente insegura». Una solución a corto plazo sería dejar de usar la sintaxis del comando. Una corrección a largo plazo implicaría mover comandos de flujo de trabajo a algún canal fuera de enlace. Pero eso también rompería otras partes del código dependiente.

Solución parcial y un mal desenlace

Tras el descubrimiento del problema de seguridad el 21 de julio, el equipo de Project Zero se puso naturalmente en contacto con GitHub. Informando sobre la vulnerabilidad, dándoles los 90 días estándar para resolverlo, que expiraría el 18 de octubre. A principios de este mes, GitHub decidió dejar de usar comandos vulnerables. Enviando un aviso sobre una «vulnerabilidad de seguridad moderada», pidiendo a los usuarios que actualizaran sus flujos de trabajo. El 16 de octubre, GitHub aceptó el período de gracia de 14 días de Google para desactivar completamente los comandos, haciendo del 2 de noviembre la nueva fecha límite.

El 1 de noviembre, GitHub solicitó al equipo de Project Zero que asignara 48 horas adicionales. Sin embargo, este período de gracia adicional no era para parchear el problema. Era para notificar a los clientes y para determinar una «fecha difícil» para solucionar la vulnerabilidad. Como esto no está en línea con el proceso de divulgación estándar de Project Zero, el problema ha sido hecho público por el equipo de seguridad con un código de prueba de concepto disponible también.

microsoftinsiderxyz

Dejar una respuesta

Please enter your comment!
Please enter your name here