Estimado GitHub,
Pues bien, la cuestión es la siguiente: existe un problema de seguridad que ha sido un secreto a voces desde hace un tiempo. La gente habla de ello en los issue trackers. Aparece en las divulgaciones de seguridad. Se discute en hilos de Slack que inevitablemente terminan con "...pero necesitaríamos que GitHub expusiera esos datos."
Le pongo esto en su conocimiento porque estoy cansado de ver cómo esa conversación termina 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 marcar referencias sospechosas. Los atacantes, mientras tanto, entienden perfectamente este punto ciego. Ya lo están explotando, tal como hizo Shai Hulud.
Nos acercamos al periodo festivo. Y me gusta pensar que me he portado bastante bien este año. Mi único deseo es que nos proporcionen las herramientas para proteger mejor el ecosistema. ¡Espero que no sea pedir demasiado!
¿Cuál es el problema?
Los gestores de paquetes como su propio npm, junto con terceros como Bun y PyPI, permiten a los desarrolladores instalar un repositorio de GitHub directamente como una dependencia. Sus propias GitHub Actions se basan 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: trusted-org/trusted-package@commit-shaLa 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 sucede: si ese commit SHA existe en un fork del repositorio, extraerás código del fork. No del repositorio de tu URL. Del fork. ¿Qué demonios?
Deja que eso asimile por un segundo. Esperaré… La URL dice trusted-org/trusted-package. Pero si un atacante bifurcó ese repositorio, añadió un commit malicioso y consiguió que hicieras referencia al SHA de ese commit, acabas de instalar su código. No el código que pensabas. No el repositorio que especificaste. El suyo.
¿Por qué ocurre esto?
Esto ocurre debido a la "Red de Forks" de GitHub.
Lo más probable es que nunca hayas oído hablar de ella. La cuestión es la siguiente: cuando bifurcas un repositorio, no obtienes una copia totalmente independiente. Tu fork se une a una red, compartiendo el almacén de objetos git subyacente con el original y con cualquier otro fork. Así es como GitHub gestiona la escala. No están almacenando un millón de copias de los mismos commits. Tiene sentido.
También es la razón por la que este ataque funciona.
Los comandos anteriores finalmente acceden al "Descargar un archivo de repositorio (tar)" endpoint. La documentación dice esto 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 un fork. ¿Sinceramente? Dada la arquitectura, este comportamiento tiene sentido. El commit existe en el grafo compartido. GitHub lo sirve. Eso no está mal.
¿Qué es El problema es que esto crea una ambigüedad que nadie más puede discernir. Usted solicita trusted-org. Recibe código de un atacante. GitHub satisfizo su solicitud. Simplemente no obtuvo lo que creía haber pedido. Y ninguna herramienta fuera de GitHub puede notar la diferencia.
La asimetría
Mire, apreciamos sinceramente que añadiera ese banner de advertencia en GitHub.com. ¿Ver una advertencia para commits como estos? Eso es útil. Demuestra que sabe que este es un problema que merece ser expuesto.
Pero aquí está la cuestión: los gestores de paquetes no consultan su sitio web. Llaman a su API. Y la API no les da ninguna indicación de que algo inusual esté ocurriendo. Ni una bandera, ni metadatos, nada documentado. Así que 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á mostrando en el frontend. Pero el ecosistema no puede acceder a ella.
¿Por qué no?
Es hora de ser estrictos
¿Recuerda ese endpoint de "Descargar un archivo de repositorio (tar)" del que hablamos? Ahora mismo, es el eslabón más débil. Pero también es el lugar obvio para solucionar esto.
Aquí hay una idea: añadir un estricto parámetro. Cuando se establece, la solicitud falla si el commit solo existe en un fork, y no en el repositorio real especificado. Los gestores de paquetes se adhieren, el resto mantiene el comportamiento actual, sin que nada se rompa.
Ya estáis realizando esta comprobación en el frontend para ese banner de advertencia. Simplemente proporcionad a la API la misma capacidad. Por supuesto, sería ideal si pudierais exponer más información de la red de forks en vuestra API en general, pero esto al menos resuelve el problema más evidente.
¡Felices fiestas!
No escribo esto como una queja. Escribo porque todos estamos alineados en el deseo de un ecosistema seguro y fiable. Ya habéis reconocido el problema al mostrar la advertencia en GitHub.com. Ahora, marcaría una gran diferencia exponer esa misma señal a través de la API para que el ecosistema pueda actuar en consecuencia.
Una pequeña mejora por vuestra parte permitiría una mejora significativa en todo el ecosistema. ¿No es ese el mejor tipo de mejora?
Y dado que es la temporada 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 tiempo libre para pasar con sus seres queridos. Solucionar este problema no eliminará ese riesgo, por supuesto, pero la preocupación es real y ampliamente sentida.
¡Felices fiestas, GitHub! Por un final de año tranquilo.
