¿Cuál es el punto de usar un sistema operativo de código abierto y seguro si lo está ejecutando en una máquina con firmware de código cerrado?

Históricamente, el movimiento de código abierto no se trata de seguridad sino de libertad . Básicamente, Richard Stallman estaba muy consternado por no poder jugar con su impresora porque la fuente del controlador no estaba disponible.

La postura de OpenBSD en cuanto a ser "seguro" no se debe a que sea de código abierto, sino a un objetivo declarado y el compromiso de hacer las cosas correctamente con respecto a la seguridad (aún históricamente, OpenBSD se creó porque algunos desarrolladores en NetBSD eran mucho mejores en la programación que en la gestión de las relaciones pacíficas entre humanos).

La asociación entre seguridad y código abierto es más reciente. De hecho, desde el principio, se explicó que era un concepto incompleto (consulte el famoso Reflexiones sobre confiar en la confianza ). Un elemento de la discusión es Ley de Linus que dice:

  

dados suficientes globos oculares, todos los errores son superficiales

La idea central es que, con suficientes revisores, se encontrarán errores, y esto se extiende a los errores relacionados con la seguridad. Sin embargo, esto se mantiene solo en la premisa de que hay hay revisores. El software de fuente abierta facilita las revisiones externas, pero eso no significa que las revisiones externas realmente se realicen. ¿Cuándo fue la última vez que revisó el código fuente existente?

Caso en cuestión: OpenSSL. Después de que se encontró otra vulnerabilidad en el código base, se creó una bifurcación, llamada LibreSSL , y comenzaron un esfuerzo explícito de revisión. , que encontró varios problemas serios en el código base. Estos problemas habían estado allí durante años, justo en el centro de una biblioteca, que se puede decir que es una de las bibliotecas más importantes relacionadas con la seguridad en el ecosistema de Linux. Así que esto fue de código abierto, y aún así no fue suficiente (en absoluto) para lograr la detección adecuada de la vulnerabilidad.

Así que, por supuesto, la apertura de fuentes ayuda con la seguridad, pero no tanto como se puede esperar.

Lo que realmente ofrece el código abierto es un riesgo mucho mayor para las personas que desean plantar puertas traseras voluntariamente. Es difícil hacer un código que parezca inocuo para los revisores y que todavía haga cosas malas (hay un concurso para dicho código).

El código abierto no es inequívocamente = más seguro / seguro

Cualquier persona PUEDE mirar el software / hardware de código abierto, pero eso no garantiza que "cualquiera" LO VEA ; Además, si lo miran, tampoco significa que divulgarán algo que encuentren que podría ser una vulnerabilidad. La gente asume demasiado acerca del código abierto, y una de las falacias que creen es que si un grupo de personas PUEDE ver algo, es de repente más seguro y más seguro. Esto no es inequívocamente cierto. Es bueno poder tener muchos ojos en el producto, pero la ética y la moral de esos ojos me preocupan tanto como su capacidad técnica.

Dicho esto, hay muchos beneficios del código abierto si el concepto subyacente se implementa correctamente.

Además, el código cerrado no es automáticamente = menos seguro / inseguro.

Pero para responder directamente a su pregunta, no, no anula automáticamente el propósito de usar un sistema operativo conocido que se preocupa por la seguridad como OpenBSD ejecutándolo sobre hardware de código cerrado, ya que el hardware en sí puede tener muchos Asegure el código / firmware detrás tanto como algo abierto.

Dejando de lado el argumento "código abierto == seguro", también puede considerar esta pregunta como "¿Por qué ejecutar un sistema operativo seguro cuando no se garantiza que el BIOS / firmware sea seguro".

¿Por qué molestarme en cerrar la puerta de mi casa cuando un atacante puede simplemente romper las ventanas?

Nunca harás un sistema completamente seguro. Lo que puede hacer es asegurarse de trabajar para asegurar las partes que son fáciles de explotar para un atacante. Es mucho más trabajo hacer explotaciones de firmware, y se limitan a apuntar a un determinado modelo de hardware. Mientras que un error del sistema operativo es más fácil de explotar y afecta a una base de destino más grande.

Así que sí, lo ideal es que quieras las dos, pero tener solo una no es inútil.

El software de código abierto (free / libre) no se trata (principalmente) de seguridad. Uno de sus aspectos más importantes es la confianza : puedes verificar lo que se está ejecutando, es mucho más difícil ocultar algo malicioso. Algunas personas también afirman que más personas leerán el código, lo que significa que es más probable que se encuentren y solucionen vulnerabilidades, lo que resulta en una mayor calidad de código. Esto ya fue discutido en la respuesta de Tom Leek en profundidad. No profundizaré en este tema discutible en esta respuesta, ya que su pregunta no es acerca de por qué el software de código abierto es más seguro, sino por qué molestarse si el firmware está cerrado.

Dejando de lado el hecho de que también el software de código abierto no es necesariamente seguro, ¿ejecutar código de confianza en firmware no confiable no hará que la ejecución de código no sea confiable? ¡Claro! Pero el vector de ataque es potencialmente más pequeño. Es mucho más difícil acceder a las interfaces de firmware del dispositivo que al acceso al sistema operativo de su computadora y al software de aplicación, que incluso puede proporcionar servicios en Internet (y muchas otras interfaces para completar extraños). Nunca habrá seguridad total, pero puede intentar minimizar el riesgo dentro de un presupuesto determinado.

Con un esfuerzo adecuado, el firmware de código cerrado (UEFI / BIOS) se puede reemplazar con el software de código abierto : Coreboot es un gran ejemplo que implementa un firmware abierto para algunos productos. Pero el UEFI / BIOS no es el único firmware : los BLOB, como el motor de administración de Intel, a veces aún son necesarios, los dispositivos de hardware como los gráficos y las tarjetas de red tienen firmware, su disco duro tiene, incluso hay un microcódigo cargado en el UPC. Y todos ellos tienen un control más o menos arbitrario sobre la memoria y / o el almacenamiento. Finalmente, incluso podría desconfiar del proveedor de CPU, que podría implementar circuitos malintencionados en hardware simple.

Debe detenerse en algún momento y simplemente confiar en el proveedor , ya que los costos aumentan considerablemente a medida que desciende la pila hacia el hardware. ¿Tiene la capacidad de verificar finalmente un diseño de CPU complejo y fabricar la CPU por su cuenta?

En el Chaos Communicaiton Congress 2015 (32C3), hubo una gran charla sobre cómo obtener Hacia (razonablemente) computadoras portátiles x86 confiables , que proporcionan un resumen sobre el tema.

No existe la seguridad total, pero uno puede hacer que sea más difícil romper la seguridad. Si bien es posible comprometer el sistema desde el interior del BIOS, UEFI, Intel SME, BIOS de la red o tarjetas gráficas, microcódigo de la CPU, mal diseño de la CPU ... esto es considerablemente más difícil que usar un error en un programa de espacio de usuario o el kernel del sistema operativo. Por lo tanto, los chicos de OpenBSD se preocupan por los problemas que pueden resolver y que realmente ayudan. Esto no significa que no estén al tanto de los otros problemas.

Siempre hay niveles más profundos que considerar, y los usuarios tienen que elegir dónde detenerse.

• Muchos chips tienen un firmware / BIOS que no se puede destapar. ¿Deseas eso, aunque nunca pudieras editarlo?
• ¿Qué pasa con el microcódigo de su procesador? Eso puede ser reemplazado (y es)
• ¿Qué pasa con el microcódigo no editable de su procesador / GPU / ...?

La única manera de estar "realmente seguro" sería tener el diseño exacto de cada chip en su máquina, y alguna forma de verificar que los chips físicos tengan ese diseño exacto, pero Intel / AMD nunca le daría eso, siempre hay un bloque en el que no puedes confiar.

El firmware suele estar agrupado con el hardware, y en la mayoría de las situaciones, se ve obligado a confiar en el hardware (a falta de una mejor alternativa). Así que terminas confiando en el firmware.

No es que esto sea algo bueno, ¡la confianza nunca está en InfoSec! Pero si confía en el hardware, no gana demasiado al no confiar en el firmware. Si quiere asustarse con este tema, vea a Ralf Weinmann hablar sobre el software de banda base que tiene cada teléfono, pero nadie piensa nunca en: enlace

Tenga en cuenta que la reciente complejidad del software BIOS (es decir, que es vulnerable a ataques), es un nuevo desarrollo en relación con la historia del campo. Debido a esto, hay muy pocas evaluaciones de amenazas completas para BIOS y software de firmware. Para lograr una situación segura, debe usar tanto el firmware seguro, ya sea de código abierto o cerrado, como un sistema operativo seguro. El uso de un BIOS de código cerrado seguro y un sistema operativo de código abierto seguro es una opción perfectamente razonable.

Como puede haber dicho, el código abierto no es igual a la seguridad. El código abierto es tremendamente transparente, lo que puede ayudar en la revisión, pero asume que la revisión se realiza. También supone que la revisión se realiza teniendo en cuenta sus intereses. ¿Está siendo revisado a un nivel de confianza?

En muchos laboratorios gubernamentales, el código de código abierto en realidad es desconfiado . Confían más en el código fuente comercial cerrado. Hay muchas razones, pero una que es especialmente relevante aquí es que el código comercial de código cerrado tiene una corporación comercial detrás. Si tienen inquietudes de seguridad particulares que desean abordar, puede ser más fácil trabajar con una empresa para resolver las inquietudes que contratar a su propio experto para que realice la revisión. Por otro lado, no hay ninguna empresa que produzca un producto de código abierto, por lo que puede ser muy difícil convencer a la legión de revisores que buscan el código de código abierto para analizar sus problemas particulares. Han descubierto que, en el caso de que los adversarios escriban intencionadamente puertas traseras que se dirigen a ellos , en lugar de apuntar a un usuario arbitrario, es mucho más fácil colarse en el código abierto y, a menudo, no son atrapados en la revisión. Una empresa tiene mucho más que perder al permitir que las puertas traseras dañen a sus clientes que un programador que escribe código abierto en su tiempo libre.

Incluso si no puedes confiar en el firmware, poder confiar en el sistema operativo (y las aplicaciones) aumenta la confianza general que puedes tener en el sistema.

Además, el firmware rara vez se usa (si es que se usa) más allá de iniciar el sistema y las posibilidades de que una vulnerabilidad o una puerta trasera afecten exitosamente al sistema operativo una vez que esté en funcionamiento son casi nada.

Te recordaría que no debes dejar que lo perfecto sea el enemigo de lo bueno.

Sí, OpenBSD está en riesgo porque se ejecuta en un firmware de código cerrado. Hay un poco de un catch-22 aquí. Las plataformas de hardware de código cerrado constituyen la mayor parte de lo que está disponible comercialmente en el mercado abierto. Por lo tanto, si desea que las personas utilicen su software / estén al servicio de cualquier otra persona, deberá ejecutar parte de ese firmware.

Desde un punto de vista de seguridad, pueden solucionar muchos problemas con la seguridad del software al escribir y ejecutar el software OpenBSD. Las vulnerabilidades que existen en el firmware suelen ser realizadas por un grupo pequeño y selecto de personas (la mayoría de los ataques de firmware son mucho más especializados).

Dado un sistema operativo de código abierto, los grupos de hardware de código abierto pueden comenzar con una base de software conocida. Sin una gran base de capital, construir ambos al mismo tiempo es prohibitivo (la mayoría de los años, OpenBSD apenas tiene la base para el software que escribe).

Hasta que exista una solución de hardware de código abierto buena y asequible , quejarse de que las personas no están utilizando una solución de hardware de código abierto parece escupir en la lluvia.