El caso de la puerta trasera de xz como microcosmos de las interacciones dentro de los proyectos de código abierto

• Hay muchos análisis sobre la vulnerabilidad de xz/liblzma, pero la mayoría tiende a saltarse la primera etapa del ataque
  • El mantenedor original se agotó, y el atacante fue el único que ofreció ayuda (por lo tanto, el atacante heredó la confianza que el mantenedor original había acumulado).
• Los archivos de hilos de correo capturan la situación en el momento en que ocurría esta etapa 0

El agotamiento del mantenedor y la aparición del atacante

• Se plantea una solicitud que parece razonable para el mantenedor

  • "¿XZ for Java sigue teniendo mantenimiento? Publiqué una pregunta hace una semana y no ha habido respuesta"

• Esta pregunta hace que el mantenedor sienta que está admitiendo un "fracaso"
  • En realidad, el mantenedor no le debía nada a nadie ni había fallado, pero así se siente
  • Porque decepcionar a la "comunidad" es algo terrible
• El mantenedor reconoce que está "quedándose atrás" y envía una señal que parece una petición de ayuda
• Sin embargo, en ese hilo no llegó ayuda, y en cambio el atacante de xz/liblzma se presentó como alguien que lo había ayudado

  • "Jia Tan (el atacante en este caso) me ha ayudado... y podría asumir un papel más grande en el futuro... mis recursos son demasiado limitados, así que está claro que algo tendrá que cambiar a largo plazo."

• El mantenedor menciona que sus recursos son limitados y que a largo plazo hará falta algún cambio

La aparición de un consumidor poco colaborativo

• Un consumidor poco colaborativo hace comentarios críticos hacia el mantenedor

  • "No parece que vaya a haber avances hasta que haya un nuevo mantenedor. ... el administrador actual ha perdido el interés o ya no le importa mantenerlo. Es triste ver un repositorio así."

• El mantenedor se defiende diciendo que no ha perdido el interés, pero que su capacidad para mantenerlo estaba limitada por problemas de salud mental, entre otras cosas
• El mantenedor también recuerda que este es un proyecto de hobby no remunerado

El aumento de las exigencias

• Una semana después, el consumidor poco colaborativo reaparece y vuelve a culpar al mantenedor.

  • "Estás ignorando una gran cantidad de parches que se están pudriendo poco a poco en esta lista de correo."

  • "Lamento lo de los problemas de salud mental, pero es importante reconocer los propios límites. Sé que este proyecto es un hobby para todos los contribuidores, pero la comunidad quiere más."

• Aunque quien hace la solicitud plantea ideas, no hay una oferta real de ayuda

  • "¿Qué tal si transfieres los permisos de mantenimiento de XZ for C para poder concentrarte más en XZ for Java? O, en cambio, pasar XZ for Java a otra persona para poder enfocarte en XZ for C. Si intentas mantener ambos, puede que ninguno quede bien mantenido."

• El mantenedor explica que no es fácil encontrar un nuevo co-mantenedor ni entregar por completo el proyecto

La realidad de los proyectos de código abierto

• Los desarrolladores de software no son engranes que se puedan poner y quitar a voluntad
• El hilo de correos termina con consumidores que expresan quejas y siguen haciendo exigencias sin ofrecer ninguna ayuda, mientras solo el atacante permanece

  • "Jia Tan quizá asuma un papel más importante en el proyecto en el futuro. Ha estado ayudando mucho fuera de la lista y, de hecho, ya es prácticamente un coadministrador. :-)"

• Este hilo de correos muestra en pequeño cómo son las interacciones dentro de los proyectos de código abierto
• Los consumidores presentan exigencias a los mantenedores, y los mantenedores responden de distintas maneras bajo estrés y agotamiento
• Esta forma de interactuar necesita cambiar

[GN⁺]

Opiniones en Hacker News

• Hay una opinión de que los desarrolladores parecen desperdiciar mucha energía mental cuando intentan ser amables con los usuarios y asumir la buena intención de quienes comentan. Este tipo de opinión surge sobre todo en side projects hechos por diversión, como emuladores o remakes de juegos. Estos proyectos evitan mencionar donaciones para no meterse en problemas con donaciones o derechos de autor. Hay mucho interés en el proyecto, pero el interés calificado que realmente puede contribuir es extremadamente limitado. Se permite y se fomenta la conversación entre usuarios, pero a veces puede percibirse como “sugerencias” o “exigencias” que desmotivan a los desarrolladores. Mantener la comunidad es importante, pero también existe preocupación por no excluir a quienes no contribuyen directamente.

• La primera etapa del problema fue un ataque de ingeniería social en el que se presionó a un desarrollador de un proyecto de código abierto para que cediera más control del repositorio al atacante.

• Como mantenedor de una librería de código abierto orientada a la seguridad, cada vez que leo un PR me pesa la duda de si “esta persona quiere ayudar o quiere aprovecharse”. Pienso que la única solución es ralentizar el ritmo de desarrollo, pero la sensación que eso genera es la misma que aparece en el artículo. Si hubiera una manera simple de pedir ayuda a una comunidad de expertos confiables, sería bienvenida en cualquier momento.

• Igual que con las criptomonedas, la IA y este incidente, el problema más grande termina reduciéndose a la confianza. Las criptomonedas intentan resolver el problema de la confianza con código, los LLM intentan ganarse esa confianza engañando con vistosidad, y el atacante logró en cierta medida lavar su confianza. Los tecnólogos más importantes no están pensando adecuadamente en la confianza. En este caso, hay comprensión hacia el desarrollador de código abierto agotado y no remunerado.

• Hay una pregunta sobre si un servidor SSH configurado con port knocking estaría a salvo de este backdoor. Como el RCE solo podría ejecutarse después de conectarse al servidor SSH, parece que no habría problema si el puerto estuviera oculto detrás de una secuencia razonable de TCP/UDP knocking. El port knocking no reemplaza una configuración adecuada de SSH, pero sirve como una capa adicional de defensa útil para prevenir el problema o ganar tiempo de respuesta cuando aparece una vulnerabilidad en SSH.

• Hay un enlace sobre un problema relacionado con un parche específico de Linux para OpenSSH. Si ese parche no hubiera existido, el problema no habría ocurrido. No es un problema de OpenSSH, sino de Linux.

• Hay una opinión de que la gente sigue tratando con descuido las dependencias fuertes y la complejidad incluso después del incidente de left-pad. OpenSSH es un muro gigantesco de código. Los sistemas complejos son intrínsecamente difíciles de confiar, sin importar en qué lenguaje estén escritos.

• Si un hacker chino quisiera actuar de forma maliciosa, ¿por qué usaría un nombre/handle chino? Para ganarse más confianza de los mantenedores de código abierto, sería mejor usar un nombre inglés o europeo. En cambio, si un hacker no chino quisiera actuar maliciosamente, tendría más sentido usar un nombre chino (China es mala, etc.).

• La cuenta de Jigar Kumar parece ser parte del ataque de ingeniería social y debería considerarse muy sospechosa.

• Los desarrolladores de software no son piezas reemplazables, y se está pensando en limitar la autoridad para comentar o participar en la comunidad. Por ejemplo, si GitHub introdujera una “puerta”, la primera podría ser añadir al suite de pruebas un test que genere un número de versión y un hash de la salida de las pruebas. Si ese número se agregara al perfil, GitHub podría confiar en que el usuario al menos descargó y ejecutó make test. Eso mostraría cierto nivel de compromiso.