Historias
Slashboxes
Comentarios
 
Búsqueda
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Posibles puertas traseras en código IPsec de OpenBSD | Log in/Crear cuenta | Top | 45 comentarios | Buscar hilo
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

  • Hoy me gustan las listas no ordenadas

    (Puntos:0)
    por pobrecito hablador el Jueves, 16 Diciembre de 2010, 00:18h (#1255926)
    • De Raadt no ha publicado eso porque se lo crea, lo ha hecho por otras cosas:
      • Es plausible, aunque no probable.
      • Si multiplicas la probabilidad de que sea cierto por las consecuencias potenciales de esto, el riesgo ya no es tan pequeño (el segundo factor es potencialmente _muy_ grande).
      • Si se hace público, las personas aludidas pueden saber porqué les pitan los oídos, y responder.
      • Si no se hace público, Gregory Perry podría decir que De Raadt no se toma tan en serio la seguridad como dice, o que oculta información.
      • Del resto de razones potenciales no estoy tan seguro.
    • Seguramente haya algún fallo de seguridad relacionado con IPSEC o OCF (OpenBSD Crypto Framework). Por ejemplo, en OpenSSL ha habido investigadores que obtenían información del tiempo que tardaban en completarse las operaciones, o de cuantas entradas de caché se utilizaban (se puede obtener una aproximación mediante los fallos de caché de un proceso que corra en el mismo núcleo). Como se suele decir, cualquier programa que no sea tan trivial como un "hola mundo" tiene fallos, y como dicen los mismos desarrolladores de OpenBSD, la diferencia entre un bug y una vulnerabilidad es la inteligencia del atacante.
    • A partir de ahora, cualquier vulnerabilidad remotamente relacionada con IPSEC que tenga una calificación mayor o igual a leve, va a ser ¡OMFG, el backdoor del FBI!
    • De todas formas, si en realidad hay un backdoor, no se va a encontrar, leed esto [csoonline.com]:

      The OCF was a target for side channel key leaking mechanisms, as well as pf (the stateful inspection packet filter), in addition to the gigabit Ethernet driver stack for the OpenBSD operating system; all of those projects NETSEC donated engineers and equipment for, including the first revision of the OCF hardware acceleration framework based on the HiFN line of crypto accelerators.

      Yo, por mi parte, me habría planteado meter un "side-channel" (¿tal vez en los LEDs? Hay un informe muy bueno sobre como reconstruir información desde los LEDs de un modem o de una tarjeta Ethernet, dados unos LEDs con un tiempo de respuesta suficientemente rápido ...) en esos aceleradores HiFN, que tienen pinta de ser caros (inaccesibles para muchos expertos en seguridad) y de ser usados por ISPs y organizaciones grandes (los "blancos" interesantes). El "backdoor" estaría en el hardware y/o el firmware de esos cacharros, y para que se usen con OpenBSD se les hacen unos buenos drivers con buena documentación.

    • Algunos ex-colegas del sujeto en cuestión comentan que es un tanto "peculiar" (en el sentido de lunático, la versión que dan es que les envía amenazas legales cada 5 años).
    • Como bien se ha dicho en otros sitios, la implementación IPSEC de OpenBSD fue la primera implementación más o menos completa con una licencia libre, muchas otras implementaciones de IPSEC se han basado en esta. Si hay un backdoor en las partes comunes, esto puede afectar a _muchos_ sistemas (IIRC incluyendo Linux 2.4 + KAME pero no Linux 2.6).