El acoso en el software de código abierto es una enorme vulnerabilidad de seguridad

Un colaborador previamente desconocido de la popular tienda de aplicaciones de código abierto para Android, F-Droid, presionó repetidamente a sus desarrolladores para que impulsaran una actualización de código que habría introducido una nueva vulnerabilidad en el software, en lo que uno de los desarrolladores describió en Mastodon como un «tipo similar». de intento como puerta trasera Xz”.

A medida que las consecuencias de la puerta trasera Xz continúan sacudiendo a la comunidad de software de código abierto, las personas que trabajan con software de código abierto se están dando cuenta (y reiterando) que una cultura en la que las personas a menudo se sienten. con derecho a actualizaciones constantes y funciones adicionales por parte de programadores voluntarios representa un desafío bastante grande. superficie de ataque.

En el caso de la puerta trasera Xz, un actor malicioso pudo presionar al propietario de una utilidad de compresión de Linux ampliamente utilizada llamada Xz Utils para que lo convierta en un mantenedor confiable del proyecto. Lo hicieron en parte argumentando que el propietario estaba engañando a la comunidad de usuarios porque no estaban publicando nuevas funciones y actualizaciones con suficiente frecuencia, a los ojos de este codificador malicioso. Puede Lea nuestro resumen completo aquí.

El martes, Hans-Christoph Steiner, desarrollador de F-Droid desde hace mucho tiempo, explicó que una situación muy similar casi llevó a F-Droid a impulsar una actualización que habría introducido una vulnerabilidad de seguridad en el producto hace tres años: “Hace tres años, F -Droid tuvo un tipo de intento similar al de la puerta trasera Xz”, dijo. publicado en mastodonte. “Un nuevo colaborador envió una solicitud de fusión para mejorar la búsqueda, que se solicitó con frecuencia pero los encargados del mantenimiento no habían encontrado tiempo para trabajar en ello. También hubo presión de otras cuentas aleatorias para fusionarla. Al final, quedó claro que agregaba una vulnerabilidad de inyección SQL. En este caso, logramos capturarlo antes de que se fusionara. Dado que se utilizaron tácticas similares, creo que ahora es relevante”.

Otros desarrolladores de código abierto y expertos en seguridad han señalado la dinámica del acoso y la dependencia general de un pequeño número de desarrolladores voluntarios. Explicaron que es un problema en gran parte del ecosistema de software de código abierto, y definitivamente es un problema para las grandes empresas de tecnología e infraestructura que dependen de estos proyectos, a menudo dirigidos por voluntarios, para construir su software con fines de lucro.

Glyph, el fundador del proyecto de código abierto del motor de red Twisted Python, dijo que la campaña de presión de Xz Utils debería “provocar un ajuste de cuentas en toda la industria con la práctica común de dejar que todo su maldito producto descanse sobre los hombros de una persona con exceso de trabajo que sufre una lenta crisis de salud mental sin apoyarla financiera operativa umente en absoluto. Quiero que todos los que tienen una dependencia de código abierto lean este mensaje.”

Luego se vincularon a un correo electrónico en el servidor de listas de Xz Utils que muestra una posible cuenta de sockpuppet argumentando: “El progreso no ocurrirá hasta que haya un nuevo mantenedor… El mantenedor actual perdió interés o ya no le importa mantener más . Es triste ver un repositorio como este”.

Meredith Whitaker, presidenta de Signal, dicho «Sigo reflexionando sobre la forma en que se habilitó la puerta trasera xz, en gran parte mediante el uso como arma del FOSS[culturadesoftwarelibreydecódigoabiertodecomportamientodemierdayabuso»[freeandopensourcesoftwarecultureofshittybehaviorandabuse”

“Lo que llama la atención es que los estándares de conducta mezquinos y desagradables de FOSS que muchos de nosotros hemos denunciado durante años, y que muchos defendieron como auténticos, duros, etc., terminaron no sólo siendo un comportamiento excluyente de perdedor, sino una importante superficie de ataque. «

En el caso de F-Droid, Steiner vinculado al hilo de GitLab donde se discutió una posible actualización específica. Este hilo muestra cómo una campaña de presión puede potencialmente comprometer un proyecto de código abierto.

En ese hilo, el desarrollador prohibido ahora que quería impulsar un código que habría agregado una vulnerabilidad exigió repetidamente que su nueva característica se integrara inmediatamente en el producto activo. Como dijo Steiner, la nueva característica habría cambiado la forma en que la gente buscaba aplicaciones en F-Droid. El usuario potencialmente malicioso argumentó que «los resultados de la búsqueda son bastante inutilizables actualmente» y propuso un nuevo código. A lo largo de los meses, ese usuario siguió escribiendo cosas como «¿queremos fusionarnos ahora?», Es decir, publicar el código y «Realmente me gustaría que esto se incluya en la próxima versión».

Cuando otros usuarios, incluido Steiner, señalaron que aún necesitaban revisar el código, modificarlo o hacer ajustes para mejorar su funcionalidad, el usuario original se enojó y otros usuarios respaldaron el cartel original.

Otro usuario, por ejemplo, argumentó: “Me gustaría fusionar esto para publicarlo pronto… ¿es perfecto? No, pero no tiene por qué ser así. Simplemente necesita ser mejor que lo que tenemos ahora”.

«La segunda gran razón por la que creo que esto debería fusionarse pronto es para alentar a nuevos contribuyentes», agregó la persona que aboga por la inclusión. “Y no diciendo ‘damos la bienvenida a las contribuciones’ y luego nunca permitiendo ningún cambio porque no son perfectos. Si las personas nunca fusionan nada, lo más probable es que nunca pasen más tiempo profundizando en el código base y abordando tareas más complejas más adelante”.

El cartel original escribió: «A riesgo de parecer grosero, creo que este es un gran cambio tal como está, y hemos pasado demasiado tiempo debatiendo implementaciones alternativas en las que no voy a trabajar (tengo un trabajo de tiempo completo y No dedicaré mi tiempo). a trabajos que creo que son peores que los que ya he hecho). Considere dejar nuevos detalles para una discusión futura o cambiar y fusionar lo que tenemos ahora”.

Steiner argumentó que el código no estaba listo para funcionar y que impulsarlo podría «romper las cosas para decenas de millas de usuarios».

“No he visto ninguna evidencia de que haya una crisis arrepentida causada por una mala búsqueda. Ha sido así desde el principio. Así que tenemos tiempo para hacerlo bien”, escribió Steiner.

El cartel original continuó presionando a Steiner ya otros mantenedores del código, y finalmente escribió «no hombre, estoy cansado de esto… No volveré a este proyecto hasta que vea que las contribuciones hechas de buena fe son bienvenidas en lugar de Luché en cada paso del camino”.

Cuando Steiner finalmente pudo auditar el código, descubrió que habría introducido una vulnerabilidad que habría permitido inyecciones de SQL, que es un tipo de pirateo muy básico que podría haber bloqueado la aplicación y también habría introducido otros problemas. Steiner escribió en ese momento que no estaba seguro de si esto era activamente malicioso o simplemente descuidado, pero señaló que era un «riesgo de seguridad» de cualquier manera.

“Me pregunto si esto fue un intento de insertar una vulnerabilidad de inyección SQL. ¿O simplemente estoy paranoico?”, escribió. «¿Alguien sabe algo sobre el remitente original?»

Steiner escribió esta semana que el codificador original eliminó su cuenta tan pronto como los mantenedores de F-Droid intentaron revisar el código, y que cree que el comportamiento del usuario, así como «toda la atención de nuevas cuentas aleatorias» le han llevado a creer «Podría ser un intento deliberado de insertar la vulnerabilidad».

En este caso, la vulnerabilidad finalmente no se trasladó a un producto vivo, sino que es un ejemplo muy específico de los tipos de presiones y cultura con los que los proyectos de código abierto enfrentan constantemente. (Un aparte: mientras estaba en el foro de F-Droid, también vi dos hilos largos en el que un usuario dijo que Steiner estaba actuando con «comportamiento de escándalo” y un profundo sentimiento porque F-Droid no había implementado adecuadamente el soporte oficial para el lenguaje artificial construido esperanto en la aplicación; Steiner explicó repetidamente que Android no era compatible con el esperanto y ese era el problema).

Independientemente de la intención, Steiner escribió que “la comunicación clara definitivamente se ve afectada cuando los mantenedores están sobrecargados, estresados ​​​​y se sienten atacados. Creo que esa es otra conclusión clave de este incidente actual. Para un actor con buenos recursos, no es demasiado difícil lograr una posición de confianza cuando los proyectos llegan a esa posición. Desafortunadamente, esto sucede con demasiada frecuencia”.