it-swarm-es.com

¿Cuál es el impacto potencial del supuesto ataque IPSEC de OpenBSD?

Recientemente hay un poco de preocupación sobre las puertas traseras de cifrado en IPsec y aunque el estado de esto no ha sido confirmado, no sé qué impacto tendrá algo como esto podría tener.

Por ejemplo, ¿significa esto que, dado que el cifrado en esta capa puede verse comprometido, tenemos vulnerabilidades en varias plataformas de tecnología de Internet (por ejemplo, SSL)?

¿Qué permite una puerta trasera que funcione aquí en términos de los ataques de Eve y Mallory?

15
Incognito

Creo que los mayores impactos estarán en el lado de las relaciones públicas.

En el lado positivo (desde el punto de vista de los mantenedores de OpenBSD), la idea de que el FBI consideró a OpenBSD lo suficientemente importante, en 2000, como para justificar la inserción de puertas traseras respaldadas por dinero, es un inflador seguro del ego. Esto por sí solo podría ser un motivo para las acusaciones públicas de puertas traseras, ya sea que existan o no. Además, la aparente divulgación inmediata y completa es un buen trabajo de relaciones públicas.

En el lado negativo, la comunicación de OpenBSD ha sido durante mucho tiempo acerca de cuánto más seguro era OpenBSD que cualquier otro sistema, gracias a la auditoría de seguridad proactiva y numerosas revisiones de código interno. Encontrar una puerta trasera de diez años justo en medio del código de la red criptográfica desinflaría un poco el mito.

Ahora, en el aspecto técnico ...

Hay muchas formas en que una alteración sutil del código podría constituir una "puerta trasera". Si tuviera que implementar una puerta trasera yo mismo, intentaría manipular el generador de números pseudoaleatorios. Es relativamente fácil hacer que PRNG parezca que produce una salida de calidad criptográfica, pero con, en realidad, una entropía interna baja (por ejemplo, 40 bits). Esto haría que las comunicaciones protegidas por IPsec sean vulnerables a descifrado con hardware común y un atacante solo pasivo (por lo tanto, indetectable). Además, un PRNG defectuoso puede atribuirse a incompetencia (porque hacer un PRNG incorrecto) fácil, pero hacer una buena no lo es), abriendo el camino a negación plausible .

Otro método de puerta trasera es la filtración de datos. Por ejemplo, siempre que tenga algunos bits aleatorios en algún paquete de red, puede hacer que estos bits contengan datos sobre el estado interno del sistema. Por lo tanto, una buena puerta trasera puede filtrar claves secretas de cifrado, que cualquiera que sepa de la existencia de la filtración puede detectar.

Los posibles desbordamientos de búfer son puertas traseras burdas, ya que solo pueden ser explotados por atacantes activos, lo que es riesgoso. Las agencias de espionaje generalmente aborrecen los riesgos. Si estos errores se encuentran en el código OpenBSD, creo que es seguro afirmar que son errores "verdaderos", no agujeros maliciosos.

14
Thomas Pornin

Como señalé en el comentario, esta es una pregunta muy amplia. Existe una amplia variedad de ramificaciones potenciales. Sin embargo, una cosa está clara: Theo acaba de conseguir un montón de revisiones de código gratuitas ;-).

Tal vez el FBI logró abrir una puerta trasera al código IPSec openbsd de la era 2001. Si lo hicieron, significa que ha habido VPN que las fuerzas del orden de EE. UU. Podrían espiar. Ahora, si lo hicieron depende de si alguien implementó la VPN en su configuración snoopable, si el FBI detectó esa implementación y si les importó.

Quizás la puerta trasera todavía esté ahí. Todo esto significa que puede aumentar el recuento de instalaciones en riesgo. Especialmente si cualquier otro sistema operativo tomó su código IPSec de OpenBSD ... FreeBSD, Mac OS X e iOS todos lo hicieron.

Ahora, ya sea que la historia sea cierta o no, es interesante notar que nadie, incluido el líder del proyecto OpenBSD, puede negarlo rápidamente. Esto, junto con las puertas traseras de Linux que han existido a lo largo del tiempo, me llevan a cuestionar la Ley de Torvalds: muchos ojos hacen que los errores sean superficiales. Aparentemente, también es posible ocultar vulnerabilidades a simple vista.

8
user185

La respuesta a su pregunta es fácil: si alguien escondió código desagradable en subsistemas privilegiados, las personas equivocadas podrían tener un control arbitrario sobre los sistemas que ejecutan el código.

Pero tenga en cuenta que no se ha presentado ninguna evidencia (y Perry debería tener mucha de eso), y no ofrece disculpas.

Para obtener más información, consulte

y los comentarios humorísticos de conspiración sobre las respuestas de los acusados: http://blog.scottlowe.org/2010/12/14/allegation-regarding-fbi-involvement-with-openbsd/http://marc.info/?l=openbsd-tech&m=129244045916861&w=2

5
nealmcb

La mejor evidencia, como la leo, es que las acusaciones de una puerta trasera en OpenBSD son mucho aire caliente. Me parece una difamación injuriosa e injustificada de OpenBSD, en un intento de difundir FUD (miedo, incertidumbre y duda).

En mi opinión, las acusaciones de Gregory Perry tienen poca credibilidad en este momento. Enumeraré algunas de las pruebas en contra de sus acusaciones:

  • Perry no proporcionó evidencia verificable en apoyo de su alegación. No ha respondido a las solicitudes de más información.
  • Las afirmaciones de la carta son intrínsecamente poco creíbles. ¿Qué agencia gubernamental le daría un NDA de 10 años que le permita hablar sobre la puerta trasera después de que pasen 10 años?) Difícilmente plausible.
  • Una auditoría de código fuente en curso de OpenBSD no ha encontrado ninguna evidencia de una vulnerabilidad en este momento.
  • La persona nombrada en la carta de Perry niega categóricamente las acusaciones . Como él explica, ni siquiera tuvo acceso al código criptográfico, ni escribió nada de ese código. Otros desarrolladores de OpenBSD se han acercado a responda por él .
  • El proyecto de software OpenBSD tenía salvaguardas para defenderse contra la introducción de puertas traseras en la forma que describe Gregory Perry, yendo tan lejos como para asegúrese de que todo el código criptográfico para IPSEC esté escrito por ciudadanos no estadounidenses .
  • Hay agujeros en la historia de Perry, en particular, el momento. Aparentemente, Perry había dejó NETSEC antes de que aparentemente se desarrollaran las puertas traseras , lo que dificulta entender cómo habría adquirido conocimiento sobre las puertas traseras si su historia fuera cierta.

Creo que es posible que NETSEC realizó estudios internos para ver cómo modificar OpenBSD para agregar una puerta trasera para su propio uso interno , pero no hay razón para creer que alguna vez se haya introducido una puerta trasera en el Distribución OpenBSD.

En pocas palabras: considero la carta de Perry, que usted citó, una difamación infundada contra OpenBSD. OpenBSD ha sido muy respetado durante mucho tiempo por su dedicación a la seguridad. Sugiero que evite redistribuir las acusaciones de Perry.

Revelación completa: no tengo ninguna asociación con OpenBSD ni con ninguna de las partes en este pequeño intercambio. No tengo ningún interés económico en este asunto. Diablos, ni siquiera ejecuto OpenBSD en mis servidores. Odio ver un buen producto sujeto a acusaciones infundadas.

2
D.W.

Esto realmente no responde a su pregunta, pero el código de alrededor de 2001 puede haber tenido cambios importantes en la última década, por lo que es difícil decir si el código todavía estaría allí de todos modos (si estuviera allí en primer lugar).

Algo más cerca de una respuesta útil: Graham tiene una lista de algunas. La siguiente pregunta es ¿cuándo empezaron a consumir ese código? ¿Antes o después de la introducción de la posible puerta trasera? Si después, ¿la empresa realizó una revisión del código? Si es así, ¿lo encontraron? Si es así, ¿lo arreglaron? Si es así, ¿lo fusionaron de nuevo con el proyecto original?

2
Steve