¿Se han realizado estudios de casos sobre vulnerabilidades intencionales o malware en proyectos de código abierto?

3

En mi experiencia, es un mantra común que el código abierto tiende a ser seguro debido a su disponibilidad para un escrutinio abierto. Tiendo a estar de acuerdo con esto. Al mismo tiempo, no es ningún secreto que las vulnerabilidades se descubren constantemente.

Además, creo que es fácil imaginar que los desarrolladores muy ansiosos obtienen bibliotecas y herramientas y que están disponibles en varios repositorios. Creo que estos recursos se toman de forma regular rápidamente para la experimentación y, a veces, se adoptan en proyectos más grandes sin mucho escrutinio (tal vez además de una verificación de compatibilidad de licencia, y cierta seguridad de que el conjunto de características coincide con lo que se desea)

Lo que me viene a la mente es PyPI, Dockerhub, etc.

Me gustaría saber si hay muchos casos documentados de cosas como:

  • Contribuciones maliciosas exitosas al software de código abierto prevaleciente
  • Los proyectos más pequeños que aparecieron y que podrían considerarse malware con el pretexto de proporcionar alguna funcionalidad simple pero atractiva
  • Informes de juego sucio en intentos intentados

Entiendo que los mejores proyectos de FOSS tienen mantenedores de alta calidad, pero también veo este mundo actual de spam continuo, phishing, pesca submarina, robo de identidad y gobiernos agresivos. Personalmente, me resulta difícil creer que los malos actores nunca tomarían un descanso al tratar de hacer contribuciones maliciosas a estos proyectos, dado que rara vez se toman un descanso de sus otras tareas desagradables.

    
pregunta andyortlieb 17.12.2016 - 05:36
fuente

1 respuesta

2

Aunque su pregunta está bien formada y es específica, las respuestas tienden a bordear el lado de la "discusión generadora" de las cosas. Voy a intentar responderte lo más directamente posible.

  

Contribuciones maliciosas exitosas al software de código abierto prevalente

No parece haber mucho en el sentido de evidencia documentada de esto. Seguramente sucedió, pero debido a la naturaleza misma de OpenSource, donde cualquier persona con conocimientos puede enviar una solicitud para actualizar el código base, siempre habrá la cuestión de si algo que termina siendo malicioso fue intencional o simplemente un error. El Heartbleed en OpenSSL pasó desapercibida durante 2 años, pero finalmente fue reportada como un error por el usuario que cargó el cambio y el administrador que lo aprobó.

  

Informes de juego sucio en intentos intentados

De vuelta en 2003 , hubo un intento de un atacante desconocido para forzar una puerta trasera en el kernel de Linux. Explotaron las prácticas de control de fuente en el momento de insertar el código directamente en un repositorio de código secundario en lugar de intentar y enviar el código para revisión por pares.

Debido a que absolutamente cualquier persona puede solicitar un cambio en el código de OpenSource, habrá una gran cantidad de casos de juego sucio. Excepto todo el drama y los informes de este suceso estarán dentro de los tableros de mensajes y otras comunidades para eso. software. El tipo que está buscando: los casos notificados dignos de noticias son mucho menos probables. Si la aplicación es lo suficientemente grande como para informar, entonces suele haber muchos pasos de aprobación para revisar el código primero.

Cuanto más grande se vuelve la aplicación, más se vuelven los ojos "potenciales" en el código. Como pirata informático, si envía un código malicioso a un control de fuente basado en una revisión por pares, como Github, está yendo y diciendo ' Espero que no esté revisando esto a fondo, porque estoy intentando hacer algo desagradable '. Sería mucho más seguro y menos probable que lo atrapen (inmediatamente, de todos modos) para intentar eliminar su código malicioso de otras maneras que no se van a auditar, como el despliegue de un ataque Man-in-the-Middle una versión modificada de la aplicación a alguien que intenta descargarla. Tendría un mayor control sobre toda la base de código y, por lo tanto, sería capaz de ocultar sus intenciones mejor y, como usted mismo sugirió, los desarrolladores y usuarios muy ansiosos son mucho menos propensos a comparar las firmas digitales de lo que están descargando que las que están descargando. rovers de aplicaciones que son la parte que más invierte en la seguridad del código.

TL; DR: como atacante, es más confiable enviar el código malicioso a un usuario final demasiado ansioso que esperar que los administradores apasionados por su producto no estén en la bola.

    
respondido por el R. Murray 18.12.2016 - 23:04
fuente

Lea otras preguntas en las etiquetas