El Fork Despierta: Por qué las redes invisibles de GitHub rompen la seguridad de los paquetes

Estimado GitHub:

Entonces, esta es la cuestión: hay un problema de seguridad que es un secreto a voces desde hace tiempo. La gente habla de ello en los gestores de incidencias. Aparece en las divulgaciones de seguridad. Se debate en hilos de Slack que inevitablemente terminan con «... pero necesitaríamos que GitHub expusiera realmente esos datos». 

Les llamo la atención sobre este tema porque estoy cansado de ver cómo esa conversación acaba siempre de la misma manera. La comunidad de seguridad solo pide visibilidad sobre los datos que ya tienen. Sin ella, estamos atascados. Los registros de paquetes no pueden advertir a los usuarios. Las herramientas de seguridad no pueden señalar referencias sospechosas. Mientras tanto, los atacantes entienden perfectamente este punto ciego. Ya lo están explotando, tal y como hizo Shai Hulud.

Se acercan las fiestas. Y me gusta pensar que este año me he portado bastante bien. Mi único deseo es que nos des las herramientas para proteger mejor el ecosistema. ¡Espero que no sea pedir demasiado!

¿Cuál es el problema?

Los gestores de paquetes como tu propio npm, junto con terceros como Bun y PyPI, permiten a los desarrolladores instalar un repositorio GitHub directamente como dependencia. Tu propio GitHub Actions se basa en esta misma primitiva.

npm install github:trusted-org/trusted-package#commit-sha

bun install github:trusted-org/trusted-package#commit-sha‍

pip install git+https://github.com/trusted-org/trusted-package#commit

- uses: organización-de-confianza/paquete-de-confianza@commit-sha

La mayoría de la gente vería esto y pensaría:«¿Dónde está el problema de seguridad? Estoy especificando literalmente el repositorio exacto».

Sí. Yo pensé lo mismo.

Pero esto es lo que ocurre: si ese SHA de confirmación existe en una bifurcación del repositorio, extraerás el código de la bifurcación. No del repositorio de tu URL. De la bifurcación. ¿Qué demonios?

Reflexiona sobre ello un momento. Esperaré... La URL dice: organización-de-confianza/paquete-de-confianzaPero si un atacante bifurcara ese repositorio, añadiera una confirmación maliciosa y consiguiera que hicieras referencia al SHA de esa confirmación, habrías instalado su código. No el código que pensabas. No el repositorio que especificaste. El suyo.

¿Por qué ocurre esto?

Esto ocurre debido ala «red de bifurcaciones» de GitHub.

Es probable que nunca hayas oído hablar de ello. La cuestión es la siguiente: cuando bifurcas un repositorio, no obtienes una copia totalmente independiente. Tu bifurcación se une a una red, compartiendo el almacén de objetos git subyacente con el original y todas las demás bifurcaciones. Así es como GitHub gestiona la escala. No almacenan un millón de copias de las mismas confirmaciones. Tiene sentido.

Por eso también funciona este ataque.

Los comandos anteriores finalmente llegan a GitHub's "Descargar un archivo del repositorio (tar)" punto final. Los documentos dicen lo siguiente sobre el propietario parámetro:

No hay garantías de que el código pertenezca directamente al repositorio, ni advertencias sobre la posibilidad de que se extraiga de una bifurcación. ¿Sinceramente? Dada la arquitectura, este comportamiento tiene sentido. La confirmación existe en el gráfico compartido. GitHub la sirve. Eso no está mal.

¿Qué? es Un problema es que esto crea una ambigüedad que nadie más puede ver a través. Pides organización de confianza. Obtienes el código del atacante. GitHub ha cumplido con tu solicitud. Simplemente no has obtenido lo que pensabas que estabas pidiendo. Y ninguna herramienta fuera de GitHub puede detectar la diferencia.

La asimetría 

Mira, realmente te agradecemos que hayas añadido ese banner de advertencia en GitHub.com. ¿Ver una advertencia para commits como estos? Es útil. Demuestra que sabes que es un problema que vale la pena sacar a la luz.

Pero aquí está el problema: los gestores de paquetes no miran tu sitio web. Llaman a tu API. Y la API no les da ninguna indicación de que esté ocurriendo algo inusual. No hay ninguna bandera, ni metadatos, ni nada documentado. Por lo tanto, npm no puede advertir a los usuarios. PyPI no puede advertir a los usuarios. Bun no puede advertir a los usuarios. La información existe. Ya la estás mostrando en la interfaz. Pero el ecosistema no puede acceder a ella.

¿Por qué no?

Es hora de ponerse estricto.

¿Recuerdas ese punto final«Descargar un archivo del repositorio (tar)» del que hablamos? Ahora mismo, es el eslabón más débil. Pero también es el lugar más obvio para solucionar esto.

Aquí hay una idea: añadir un estricto parámetro. Cuando está activado, la solicitud falla si la confirmación solo existe en una bifurcación, no en el repositorio real especificado. Los gestores de paquetes se activan, todos los demás mantienen el comportamiento actual, nada se rompe.

Ya estás realizando esta comprobación en la interfaz para ese banner de advertencia. Solo tienes que dotar a la API de la misma capacidad. Por supuesto, lo ideal sería que pudieras exponer más información sobre la red fork en tu API en general, pero al menos esto resuelve el problema más evidente.

¡Felices fiestas!

No escribo esto como una queja. Escribo porque todos coincidimos en querer un ecosistema seguro y fiable. Ya has reconocido el problema al publicar la advertencia en GitHub.com. Ahora sería muy importante exponer esa misma señal a través de la API para que el ecosistema pueda actuar en consecuencia.

Una pequeña mejora por tu parte permitiría una mejora significativa en todo el ecosistema en general. ¿No es ese el mejor tipo de mejora? 

Y como estamos en época navideña, quiero compartir algo que he estado escuchando entre bastidores. En las últimas semanas, he hablado con algunos de los actores más importantes del ecosistema, y existe una preocupación silenciosa y compartida de que algo pueda salir mal mientras todos intentan tomarse un descanso para pasar tiempo con sus seres queridos. Por supuesto, solucionar este problema no eliminará ese riesgo, pero la preocupación es real y muy extendida.

Felices fiestas, GitHub. Brindemos por un final de año tranquilo.

‍