¿Ejemplo de un backdoor enviado a un proyecto de código abierto?

Question

¿Ejemplo de un backdoor enviado a un proyecto de código abierto?

#1 de Bruce Ediger (15 votos)
#2 de sh4d0w (8 votos)
#3 de guaka (1 votos)
#4 de AJ Henderson (0 votos)

22

Para aclarar de inmediato, no estoy interesado en escribir una puerta trasera. No tengo ningún interés en enviar listas de cambios de puerta trasera a proyectos yo mismo.

Estoy investigando algunas técnicas de modelado de fuentes, y estamos interesados en ver si se pueden identificar vulnerabilidades o códigos maliciosos. Estamos utilizando los historiales de git y subversion para examinar cómo una instantánea modelo captura las relaciones entre el código. Existe una pregunta sobre si ciertos tipos de código aparecen como valores atípicos en un entorno como este.

Teniendo eso en cuenta, me cuesta mucho encontrar ejemplos de git / cvs /? El repositorio de código abierto con un ejemplo de una lista de cambios que contenía una puerta trasera, se envió y se mostrará en los registros.

Estábamos viendo proftpd como ejemplo anterior , pero esta vulnerabilidad no se verificó en otras versiones modificadas del código.

¿Hay ejemplos en el historial de revisiones de un proyecto de código abierto de intentos de insertar código de puerta trasera?

Nota: Envié esto a StackOverflow un rato Hace , pero estaba cerrado. Estoy revisando esto ahora, y la recomendación fue preguntar aquí. Gracias!

attacks source-code exploit

pregunta swrittenb 29.10.2012 - 15:45

fuente

4 respuestas

Lea otras preguntas en las etiquetas attacks source-code exploit

¿Por qué un ataque (D) DoS ralentiza la CPU y bloquea un servidor? ¿Rehashing un hash débil con un algoritmo fuerte lo hace fuerte?

score 15 · Answer 1

Algunas notas sobre un intento de obtener una puerta trasera en el kernel de Linux, circa 2003. Aparentemente sin éxito. El comentario contemporáneo fue bastante interesante.

Las máquinas de distribución del kernel de Linux se se pusieron en peligro nuevamente en 2011 , pero parece que no se ha cambiado ningún código esa vez.

ACTUALIZACIÓN: Parece que un espejo de sourceforge tenía una versión de phpMyAdmin con una puerta trasera integrada .

score 8 · Answer 2

Hubo una puerta trasera en e107 CMS en 2010: enlace

Hace dos meses (septiembre de 2012) phpmyadmin tenía una puerta trasera de uno de los repositorios / mirrors de SourceForge: enlace

Se alega que el FBI tuvo una pila IPSEC de OpenBSD de puerta trasera en 2000: enlace

Opensource tiene muchas ventajas en comparación con el código cerrado, pero esto no significa que un proyecto de código abierto pueda ser seguro debido a su naturaleza. La prueba de penetración continua es musthave.

score 1 · Answer 3

La nota clave de FOSDEM 2014 por Poul-Henning Kamp (arquitecto principal de Barniz y Ntimed) es muy interesante:

Este es un informe ficticio de la NSA que presenté como nota clave de cierre en   FOSDEM 2014

La intención era hacer que la gente se riera y pensara, pero yo   desafía a cualquiera a demostrar que no es cierto.

Todo es ficción, pero es ficción de alguien con mucha experiencia en proyectos de código abierto.

Aquí está el video de 45 minutos .

Y luego está Cómo la NSA (puede haber) puso una puerta trasera en la criptografía de RSA: Un manual técnico en el blog de CloudFlare.

score 0 · Answer 4

Creo que la mayor protección que tienen la mayoría de los proyectos de código abierto es simplemente quién obtiene acceso. Como en general, no todos pueden enviar código a un proyecto, aquellos a quienes se les ha otorgado acceso a los mismos tienden a ser lo suficientemente activos como para que no valga la pena intentar comprometerse de esa manera. (Es más fácil tratar de encontrar un exploit existente ya que la fuente está disponible). Incluso si tratara de hacer un compromiso abusivo, estaría haciendo un gran esfuerzo y enfrentando una posibilidad decente de que su pícaro se comprometa. detectado por otros antes de alcanzar un lanzamiento importante, por lo tanto, te quemas del proyecto y abandonas todo el trabajo que hiciste.

Básicamente, debido a que la dificultad es alta y el potencial de recompensa es bajo, simplemente no vale la pena tratar de comprometer maliciosamente un proyecto de código abierto. El único lugar donde podría verlo intentado (desde el punto de vista del riesgo frente a la recompensa) sería el gobierno que lo intentara, pero en ese caso, probablemente estaría con al menos algún nivel de apoyo al proyecto y se ocultaría con cuidado. También sería muy difícil hacerlo sin la eventual detección de la mayoría del software, por lo que es bastante improbable incluso en ese momento.