¿Cómo escalar un problema de seguridad de una biblioteca cuando al autor no parece importarle?

4

Hay una biblioteca de código abierto que es terriblemente insegura. El autor reconoce que es inseguro. El titular de la biblioteca dice "Esta es una implementación para la plataforma X de la Biblioteca Y". La biblioteca Y es segura, por lo tanto, el titular de que su biblioteca es una implementación de una biblioteca segura Y sugiere que su implementación también sea segura. En ninguna parte su biblioteca o es readme y los documentos mencionan que es inseguro.

Lo mencioné educadamente, enumeré los problemas y le sugerí cortésmente que agregara una advertencia al archivo Léame. Dijo que no creía que nadie pensara que su biblioteca está segura. Señalé que él afirma que su biblioteca es una implementación de Y, y se sabe que YY está diseñada para ser segura. Respondió que vio mi punto de vista y sugirió que envié una solicitud de extracción para actualizar el archivo Léame. Yo si. Eso fue hace 12 meses. Otros lo han mencionado, pero no hay movimiento.

También permítame agregar que su biblioteca no es en realidad una implementación de Y. Es similar, pero necesitaría meses de trabajo para pasar las pruebas de conformidad de Y, por lo que además de ser insegura, también está mintiendo sobre ser una implementación de Y.

¿Qué pasa si hay algo que deba decir que pueda fomentar el movimiento? Mi instinto (que sé que está mal) es básicamente decir que es un imbécil por engañar a la gente y poner a la gente en riesgo y que realmente debería tomar el asunto más en serio. No es la biblioteca más popular, pero según al menos un punto de distribución, se ha descargado 160 veces este mes y hay algunas bibliotecas dependientes. Suponiendo que es un promedio por mes, entonces hasta 1920 personas / proyectos están en riesgo.

    
pregunta gman 12.10.2017 - 00:53
fuente

2 respuestas

5

Obviamente, el autor ya no considera que su proyecto sea una prioridad. Eso no es raro. Hay demasiados problemas interesantes en el mundo y muy poco tiempo para resolverlos todos, por lo que los proyectos tienden a abandonarse. Esto incluye proyectos con problemas de seguridad conocidos. Todo lo que puede hacer es hacer que la gente sepa que esta pieza de software es insegura.

  • Reporte las vulnerabilidades a la Base de datos de vulnerabilidad de NIST .
  • ¿El proyecto tiene un bugtracker público? Entonces deberías reportar las vulnerabilidades de seguridad como errores. Las personas que evalúan el software de código abierto que consideran usar usualmente revisan el bugtracker para obtener una impresión de qué tan bien mantenido está. Múltiples errores abiertos relacionados con fallas de seguridad críticas generalmente serán una gran señal de alerta.
  • Póngase en contacto directamente con los proyectos dependientes que la biblioteca que están utilizando tiene fallas graves de las que tal vez no estén al tanto.

Cuando te sientas altruista, podrías solucionar los problemas tú mismo. Envíe un parche o haga una solicitud de extracción cuando esté en GitHub. Cuando el autor haya perdido el interés por completo, es posible que desee sugerir que se lo quite y se convierta en el responsable oficial. Cuando el autor es completamente poco cooperativo, podría comenzar un tenedor.

    
respondido por el Philipp 12.10.2017 - 17:17
fuente
-4

Generalmente, cuando el vendedor no responde adecuadamente, usted divulga públicamente las vulnerabilidades. Puedes publicarlo en Exploit-db o algo así.

    
respondido por el Daniel Grover 12.10.2017 - 17:20
fuente

Lea otras preguntas en las etiquetas