Pregunta:
¿Cómo se mantienen seguros los sistemas operativos y el software de código abierto?
Jim
2012-02-02 00:45:06 UTC
view on stackexchange narkive permalink

Me he estado preguntando por el suyo durante un tiempo. Tengo Linux ejecutándose en una PC en casa. Tenía un iPhone con jailbreak. Ambos tienen atributos que los hacen muy atractivos, ¡y además son GRATIS! Pero no he podido encontrar nada que explique cómo se mantienen a salvo de los caballos de Troya. Supongo que no puedo ejecutar un escáner de virus en los archivos de origen para ver si son seguros. Si puedo, no sé cómo hacerlo.

¿Qué tan seguro debo estar acerca de la seguridad con Linux y iPhones con jailbreak? ¿Qué evita los agujeros de seguridad intencionales causados ​​por manos privadas o gubernamentales?

Entiendo que existen riesgos incluso con los sistemas operativos desarrollados de forma privada, pero en esos casos, tengo cierta idea de quién tiene la responsabilidad de ellos. No es así para estos dos casos y para otro software de código abierto o de fuente colectiva.

Este artículo de Wikipedia es tan bueno como cualquier otro lugar para empezar. http://en.wikipedia.org/wiki/Open_source_software_security
[Esta pregunta] (http://security.stackexchange.com/questions/4441/open-source-vs-closed-source-systems) también podría ser de interés. En cuanto a la seguridad de los sistemas de código cerrado, el lamentablemente llamado [`_NSAKEY`] (http://en.wikipedia.org/wiki/NSAKEY) también podría ser una lectura interesante, en última instancia inofensiva (de hecho, beneficiosa), sin embargo, ciertamente creó cierta controversia.
Yo no diría que iOS es "GRATIS". de cualquier forma práctica, está ligado a hardware (caro) y el código es mayormente propietario.
Seven respuestas:
Tom Leek
2012-02-02 02:50:42 UTC
view on stackexchange narkive permalink

La teoría es:

  • El software de código cerrado en su mayoría no es troyano porque el proveedor de dicho software es legalmente responsable del contenido del software, y rastrear fácilmente, en caso de que se revele que un código malicioso oculto es parte de él (por ejemplo, mediante ingeniería inversa).

  • El software de código abierto en su mayoría no contiene troyanos porque Es muy difícil pasar de contrabando código adicional discretamente cuando el código fuente está a la vista de todos. Es de suponer que otras personas leen con regularidad el código de fuente abierta, por lo que pronto se detectarán las puertas traseras.

La práctica es:

  • El software de código cerrado en su mayoría no tiene troyanos porque nadie se molestó en colocar una puerta trasera en él.
  • El software de código abierto no tiene troyanos en su mayoría porque nadie se molestó en colocar una puerta trasera en él.

Si tuviera que incluir una puerta trasera en un sistema operativo de código abierto, intentaría ponerlo en el generador de números aleatorios. Escribir un RNG adecuado y seguro es difícil, por lo que es probable que algunas alteraciones oscuras pasen desapercibidas pero den como resultado un resultado predecible, por lo tanto, un resultado predecible de la generación de pares de claves (por ejemplo, para claves SSH) y cosas por el estilo. Y debido a la dificultad de escribir un RNG adecuado, todavía podría alegar de manera plausible mera incompetencia, no malicia, en caso de que se descubriera la puerta trasera. Caso en cuestión: hace aproximadamente un año, hubo tales rumores de puerta trasera en el código RNG en OpenBSD (aparentemente, los rumores resultaron ser infundados; sin embargo, confieso que no verifiqué el código yo mismo).

Lo que debe recordarse es que tanto la detección de puertas traseras (en código fuente o código compilado) como la instalación de puertas traseras sin ser detectadas son artes difíciles. Los espías profesionales aborrecen la indiscreción; trojaning se suele considerar "demasiado arriesgado".

Me gustan tus comentarios de 'práctica', tan cierto
Luego, por supuesto, estaba el [error en Debian Linux] (http://www.schneier.com/blog/archives/2008/05/random_number_b.html) hace unos años, donde resultó que alguien acababa de * eliminar * el código de siembra PRNG de OpenSSL, lo que provoca que todos los números aleatorios que usaba y debían ser, eh, ** no aleatorios en absoluto ** ([ver también] (http://www.xkcd.com/424))
Gilles 'SO- stop being evil'
2012-02-02 05:22:35 UTC
view on stackexchange narkive permalink

El software de código abierto es menos confidencial que el software de código cerrado, pero eso no es relevante cuando se consideran las puertas traseras, a diferencia de las vulnerabilidades en general que casi siempre son accidentales. En esta respuesta, solo abordaré las puertas traseras, y no los problemas más amplios de las vulnerabilidades en general (solo una fracción insignificante de las vulnerabilidades son deliberadas). Para combatir las puertas traseras, necesita controles estrictos sobre la calidad e integridad del código. Dichos controles no se debilitan intrínsecamente al hacer público el código.

Integridad: lo que hacen es lo que obtienes

Por integridad, me refiero a la seguridad de que el código ' re running es el código que escribieron los desarrolladores . Esto requiere que la cadena de distribución sea rastreable o que los desarrolladores firmen el código con una firma que usted reconozca. La firma se practica comúnmente cuando se desea un software seguro; El código cerrado y el código abierto están en pie de igualdad. La distribución funciona de manera diferente, sin una ventaja clara para ninguna de las partes: el código cerrado tiende a tener distribución directa (se obtiene directamente del proveedor), mientras que el software de código abierto tiende a replicarse muchas veces, lo que aumenta las oportunidades de manipulación y aumenta el oportunidades para detectar alteraciones.

Hay una segunda parte de la integridad, que está dentro del dominio de los desarrolladores. Con el software de código cerrado, confía en los controles internos del proveedor de software. Por lo general, esto no es algo sobre lo que tenga visibilidad directa; la única fuente de información algo independiente son las certificaciones de seguridad del proveedor, y solo brindan cierta garantía. En el lado del código abierto, la mayoría de los proyectos de alto perfil tienen repositorios públicos hoy en día, lo que hace que cada cambio en el código fuente sea rastreable públicamente. En teoría, eso es: la integridad del código fuente rara vez se verifica, pero existe la posibilidad de que se detecte una infracción por casualidad. En la práctica, en ambos lados, el nivel de controles de integridad está por todo el mapa; código abierto versus código cerrado no es un factor discriminatorio .

En puertas traseras introducidas por los autores

Integrity le dice que solo los desarrolladores documentados produjeron el código . La calidad te dice si introdujeron una puerta trasera (ya sea intencionalmente o subvertidos). Con un proveedor de código cerrado, es raro tener una garantía de calidad más allá de la reputación del proveedor y posiblemente certificaciones (suponiendo que crea que indican calidad; de hecho, las certificaciones pueden implicar una verificación de antecedentes penales de los desarrolladores, pero es poco probable que detecte puertas traseras sutiles). Con el código fuente abierto, en teoría, el código está a la vista de cualquiera. Nuevamente, en la práctica, nadie mira la mayor parte; pero como el nombre del desarrollador está asociado públicamente con cada fragmento de código, el autor de una puerta trasera corre el riesgo de quedar expuesto. Suponiendo que la puerta trasera se identifique como tal: la mayoría de las vulnerabilidades son accidentales, después de todo.

Es interesante observar una puerta trasera famosa, que fue presentada por Ken Thompson en Unix. Le insto a leer su discurso de aceptación del Premio Turing, "Reflexiones sobre la confianza en la confianza", que reveló la puerta trasera. En pocas palabras, Thompson modificó el compilador del sistema para agregar algún código al programa de inicio de sesión que le permitiera iniciar sesión en cualquier cuenta. Luego modificó el compilador para insertar el código para esta modificación del compilador al compilar el compilador, y volvió a compilar el compilador. Finalmente revirtió las fuentes del compilador para no hacer nada especial. A partir de ese momento, el compilador perpetuaría la puerta trasera aunque no hubiera nada visible en el código fuente. Esto muestra que no es suficiente rastrear el historial del código fuente: se debe rastrear el historial de todo el sistema, incluido el origen de cada programa y archivo de datos involucrado en la construcción del sistema en cualquier momento.

La puerta trasera de Thompson confiaba en tener el control del compilador. Es posible inyectar una puerta trasera en una aplicación de una manera similar dado el control del sistema de construcción o distribución, del sistema operativo o del hardware. Por otro lado, el autor de una aplicación no puede ocultar una puerta trasera tan fácilmente. Allí, la puerta trasera realmente tiene que estar presente en el código fuente. Es más fácil detectar una puerta trasera en el código fuente que en un ejecutable, si sabe lo que está buscando: muchas puertas traseras son obvias en el código fuente si piensa en buscar en el lugar correcto, mientras que probar la presencia de una puerta trasera en un ejecutable binario requiere más trabajo con un depurador.

Puerta trasera en el algoritmo

En casos excepcionales, las puertas traseras se pueden ocultar en un algoritmo. Esto surge en la criptografía: muchos algoritmos involucran “constantes mágicas”, que pueden elegirse de manera algo arbitraria. Los buenos diseños criptográficos usan "números de nada en la manga": por ejemplo, MD5 usa constantes derivadas de valores de la función seno. Como contraejemplo, las curvas elípticas estandarizadas por NIST en FIPS 186-3 implican constantes que parecen aleatorias. Sin embargo, es posible que las constantes se hayan derivado de un valor secreto, y saber ese valor facilitaría la ruptura de la criptografía con estos algoritmos. Es imposible probar que el NIST (o la NSA) de hecho no derivó las constantes de un valor secreto que conocen.

En este caso, no importa el código abierto frente al código cerrado. . Incluso si está seguro de que el software implementa el algoritmo correctamente, también debe confiar en el diseñador del algoritmo.

Una mirada al software de consumo

Algunas plataformas han preferido formas de instale el software por encima del sistema operativo base. En las plataformas móviles, el software se distribuye normalmente a través de un canal controlado por el proveedor de la plataforma (App Store, Android Market,…). Este canal garantiza que lo que obtiene es lo que el proveedor de la plataforma quiere que obtenga. Como tal, lo protege contra terceros maliciosos que podrían intentar engañarlo para que instale una versión con troyanos de una aplicación legítima. Esto no protege contra una aplicación que es maliciosa en primer lugar, ya que los proveedores de plataforma solo realizan verificaciones extremadamente superficiales en las aplicaciones que distribuyen, si las hay.

En el lado del escritorio, el software comercial generalmente se distribuye directamente a los consumidores o a través de terceros generalmente confiables (ISP, en los viejos tiempos, el correo o las tiendas físicas). El software libre es otro asunto. La mayoría de las distribuciones de Linux incluyen una gran cantidad de software y firman paquetes de aplicaciones. Al igual que en el caso de los dispositivos móviles, los fabricantes de paquetes no hacen más que verificaciones superficiales (aunque rechazan las aplicaciones que parecen poco fiables), por lo que no puede contar con que detecten una puerta trasera introducida por el autor de la aplicación. Pero puede limitar su confianza a los autores de la aplicación y los encargados de la distribución, ya que la infraestructura de distribución protege contra la manipulación por parte de terceros. Si alguna vez se descubre una puerta trasera, puede contar con que se corregirá rápidamente y que recibirá actualizaciones de seguridad tan pronto como estén disponibles. Mac OS X tiene canales de distribución similares (una tienda oficial y varios distribuidores de software gratuito).

El mundo de Windows es diferente: los usuarios de Windows suelen instalar una gran cantidad de software de terceros sin costo a través de canales sin controles , y estos no tienen ningún mecanismo de actualización automática. Puedo trabajar cómodamente en una PC con Ubuntu con muy poco software que Ubuntu no proporciona en un paquete firmado; en Windows necesito muchos programas de terceros (un navegador web, un procesador de texto, muchos applets de “productividad”,…). Esto, junto con el hecho de que los atacantes apuntan más a Windows porque la mayoría de las víctimas potenciales ejecutan Windows, aumenta el riesgo de puertas traseras. No directamente porque Windows sea de código cerrado, sino porque carece de una infraestructura de distribución de aplicaciones. Dichas infraestructuras pueden funcionar tanto en el mundo de código abierto y gratuito como en el mundo de código cerrado de pago.

Consideraciones generales

Es difícil estar seguro de la historia de las puertas traseras o obtener estadísticas precisas, porque, por definición, las que realmente tienen éxito son aquellas que no conocemos. Sin embargo, la capacidad de descubrir intentos fallidos puede resultar instructiva. Con respecto al kernel de Linux, hubo un famoso intento de inyectar una puerta trasera que fue detectada por una inconsistencia en el control de fuentes. Puede ver cómo se desarrolla el descubrimiento en la lista de correo del kernel de Linux; ha habido muchas redacciones, p. ej. en Kerneltrap, SecurityFocus.

En general, no veo un ganador intrínseco entre el software de código abierto y el de código cerrado fuerte>, cuando se trata de puertas traseras. El software de código abierto tiene el potencial de alcanzar el mismo nivel de seguridad que el software de código cerrado, al tiempo que mantiene las ventajas que ofrece una amplia exposición. Ciertamente, puede tener a alguien que se haga responsable del software de código abierto, si está dispuesto a pagar por él. Por lo tanto, el software de código abierto puede alcanzar un nivel de seguridad más alto, pero esto no significa que lo haga en todos los casos.

Hay una forma en la que el código abierto gana: si estás preocupado por una puerta trasera específica en una aplicación específica (a diferencia del sistema en su conjunto). Con el código fuente abierto, puede mirar la fuente y ver si hay una contraseña maestra o si los números aleatorios se generan correctamente.

Buenos comentarios. Supongo que se detectaría fácilmente si se comprometiera el repositorio principal de una distribución de código abierto firmada, ya que la verificación de firmas fallaría. Y cada copia extraída probablemente tendría un historial de cambios completo con firmas intactas. Entonces, las personas que controlan la distribución podrían recuperarse con bastante facilidad. Sin embargo, ¿por qué confiamos en esas personas? ¿Dónde puedo tener una mejor idea de cómo funciona realmente ese proceso (con Linux, por ejemplo)?
@Jim Hace unos años, hubo un famoso intento de insertar un agujero raíz en el kernel de Linux. Muchos [hits de Google para Linux + backdoor] (http://www.google.com/search?q=linux+backdoor) lo discuten, p. Ej. [SecurityFocus] (http://www.securityfocus.com/news/7388), [descubrimiento en lkml] (http://lkml.indiana.edu/hypermail/linux/kernel/0311.0/0635.html), [Kerneltrap ] (http://kerneltrap.org/node/1584). El intento fue descubierto por una inconsistencia en el control de fuentes.
@Jim Además, supongo que está familiarizado con la famosa puerta trasera Unix de Ken Thompson. Si no es así, deje todo y lea [Reflexiones sobre la confianza en la confianza] (http://cm.bell-labs.com/who/ken/trust.html). La introducción de la puerta trasera implicó cambiar el código, recompilar el compilador y volver a cambiar el código. Un sistema de compilación y control de fuente totalmente auditable lo habría detectado (o al menos habría dejado la evidencia visible).
Respuesta impresionante. TL; Versión DR: "¿Quién vigila a los espectadores?" Este [no es un problema nuevo] (https://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F)
Excelentes ejemplos también. Ese ejemplo de Linux es alentador: alguien estaba observando de cerca. Creo que eso no podría suceder hoy, debido a la naturaleza distribuida de git, pero te hace pensar. ¿Qué tan difícil sería para una agencia gubernamental o corporativa con recursos suficientes piratear la computadora portátil de uno de los desarrolladores principales de Linux y reemplazar los binarios de git con algo que haga una modificación menor a una confirmación grande y la oculte? No estoy seguro de qué tan buenos son los procesos de revisión del kernel de Linux, pero algo tan pequeño puede escaparse fácilmente de las manos de uno o dos revisores ...
Rory Alsop
2012-02-02 01:17:59 UTC
view on stackexchange narkive permalink

Con el software de código abierto, cualquiera puede ver y analizar el código, por lo que este modelo tiene mucho que ofrecer. Muchos ojos, etc.

El problema surge cuando tiene una base de código masiva y no tiene suficientes ojos calificados y experimentados; las cosas pueden deslizarse por la red.

Sin embargo, con el código cerrado código, básicamente está poniendo su confianza en los desarrolladores: ¿cómo sabe que han analizado correctamente el código? Por experiencia, he encontrado una gran cantidad de proveedores que no han realizado ninguna revisión de código o lo han hecho tan mal que hay grandes lagunas en las aplicaciones, y si lee algún aviso, verá cuántos son por errores u omisiones. en prácticas de codificación!

No estoy seguro de si el código abierto o cerrado gana en conjunto, pero soy un firme partidario de la idea de que todos los proveedores de software deben tener una revisión de código independiente y una prueba de penetración ( por probadores de penetración aprobados) de todo el código antes de su lanzamiento.

Si los desarrolladores fueran responsables ante la ley, de todos sus errores, entonces el software estaría libre de errores, y también habría muchos menos.
De hecho ellos son. Es por eso que le advierten que el software no está garantizado en absoluto o de ninguna manera, y que si elige usarlo, acepta explícitamente usarlo solo bajo su propio riesgo.
zedman9991
2012-02-02 03:00:41 UTC
view on stackexchange narkive permalink

En cuanto a la seguridad de los sistemas de código abierto, prefiero considerar ejemplos análogos del mundo físico, como una cerradura de puerta sobre el argumento de muchos ojos, ya que muchos ojos han pasado por alto vulnerabilidades durante años (por ejemplo, unir). Los detalles de todas las cerraduras de las puertas de entrada son bien conocidos y comprendidos, pero ese conocimiento hace poco por disminuir su seguridad. La seguridad de esa cerradura proviene de su sólido diseño y construcción. Expone las cabezas de los tornillos al interior de la casa (si es que lo hace); está construido con metal resistente, y así sucesivamente.

Lo mismo ocurre con un buen código fuente abierto. Una buena construcción con un buen diseño proporciona una seguridad sólida a pesar del plano disponible públicamente. Eso nos lleva a cómo confirmamos la construcción del software. En mi opinión, una distribución popular de Linux con un control de hash tranquilizador es un gran comienzo.

El jailbreak se encuentra en una categoría diferente. Para mí, eso es análogo a quitar la placa frontal de la cerradura de nuestra casa y modificar el sistema de cerradura. Yo mismo podría hacer eso, pero personalmente sería reacio a dejar que un completo extraño lo hiciera por mí. Por definición, un jailbreak aprovecha una vulnerabilidad de seguridad para permitir "rootear" su sistema.

doyler
2012-02-02 01:14:42 UTC
view on stackexchange narkive permalink

En lo que respecta al software libre, una gran cantidad de miembros de la comunidad de seguridad siempre ha opinado que la seguridad pública es mejor. ("La seguridad pública es siempre más segura que la seguridad patentada ... Para nosotros, el código abierto no es solo un modelo de negocio; es una práctica de ingeniería inteligente" - Schneier). El razonamiento detrás de eso es que sí, los "malos" pueden ver su código, pero también los buenos. Las cosas que puede haber pasado por alto y que los "malos" pueden encontrar fácilmente, los "buenos" podrán señalarle, mientras que si nadie pudo ver su código, es posible que se hayan encontrado demasiado tarde.

Eso, combinado con el hecho de que también puede desarrollar escáneres / herramientas para protegerse mucho más fácilmente, no está de más.

Bernard
2012-02-02 01:19:54 UTC
view on stackexchange narkive permalink

Muchos ojos pueden mirar el código y detectar agujeros de seguridad si el código está abierto al público. Así es como se mejora y aprueba el código de fuente abierta, que generalmente es el objetivo del software de fuente abierta. De lo contrario, es mejor que espere que su código de fuente cerrado no tenga problemas de seguridad.

Abrir ojos 'hábiles / experimentados' es el desafío :-)
@RoryAlsop: Debería consultar algunos de los informes de errores en varios OSS conocidos más grandes, hay personas que están al borde de la locura en el desarrollo de código abierto.
user unknown
2012-02-02 16:27:01 UTC
view on stackexchange narkive permalink

Para detectar vulnerabilidades, puede hacer todo con OpenSource, lo que puede hacer con ClosedSource (ingeniería inversa, pruebas difusas, ejecutarlo detrás de un proxy, que rastrea todo el tráfico), además puede leer la fuente.

Una ventaja, que no se ha mencionado, es que los proyectos OpenSource tienden a compartir mucho código con otros proyectos OpenSource, lo que significa que el mismo código se usa en más software.

Si es utilizado por más partes, se prueba con más frecuencia, se revisa con más frecuencia y se expone con mayor frecuencia a intentos de romperlo, por lo que la posibilidad de observar una debilidad es mayor.

Por supuesto, esta idea tiene sus debilidades. También hay nuevas bibliotecas en FOSS y también hay bibliotecas CS, vendidas y reutilizadas.

Un gran problema con el código cerrado es el software pirateado. Los usuarios de software pirateado no pueden quejarse del mal funcionamiento y los usuarios que violan la protección de los derechos de autor también pueden insertar puertas traseras. En FOSS, no es necesario adquirir software pirateado, por lo que no hay un tercero interesado que coloque puertas traseras intencionalmente en el código. Pero, por supuesto, siempre puede pagar por su software cerrado que solicita regularmente, y luego no se verá afectado con CS.

A otro aspecto: el argumento de la empresa responsable para CS no se sostiene:

Los desarrolladores de FOSS también tienen que perder un nombre, y supongo que todas las jurisdicciones son similares en que no puede negar la responsabilidad por daños en el EULA o una licencia por mala intención. Bueno, puede negarlo en el texto, pero será nulo.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...