Recientemente en GoTo Chicago di una conferencia sobre este tema y pensé que sería bueno escribir un artículo con conclusiones. Esta publicación trata sobre por qué el firmware de código abierto es importante para la seguridad.
Niveles de privilegio
En una pila típica, tienes diferentes niveles de privilegio.
- Anillo 3. Aplicaciones: privilegios mínimos, con la excepción del entorno limitado en el espacio del usuario, que es aún más limitado.
- Anillo 0. Kernel: el kernel del sistema operativo, en el caso de un sistema operativo de código abierto, verá su código.
- Anillo −1. Hypervisor: Virtual Machine Monitoring (VMM), crea y ejecuta máquinas virtuales. En hipervisores de código abierto como Xen, KVM, bhyve y otros, verá el código.
- Anillo −2. Modo de gestión del sistema (SMM), núcleo UEFI: código propietario, más sobre esto a continuación.
- Anillo −3. Motor de control: código propietario, más sobre esto a continuación.
Los anillos negativos indican niveles con privilegios mayores que cero.
De lo anterior, está claro que en los anillos de -1 a 3, tenemos la oportunidad de usar software de código abierto, en gran medida verlo y controlarlo. Para niveles por debajo del anillo -1, tenemos menos control, pero la situación está mejorando gracias al desarrollo de firmware de código abierto y la comunidad.
Esta es una situación contradictoria: el código más cerrado tiene más privilegios en nuestro sistema. Esta paradoja debería arreglar el firmware de código abierto.Anillo −2. SMM, núcleo UEFI
Este anillo controla todos los recursos de la CPU.
El Modo de administración del sistema (SMM) es invisible para el resto de la pila que se encuentra encima. Tiene la mitad del núcleo. Originalmente utilizado para administración de energía y control de hardware del sistema. Contiene una gran cantidad de código de propiedad y es el lugar donde los proveedores agregan nuevas características de propiedad. Maneja eventos del sistema, como errores de memoria o chipset, así como un montón de otras lógicas.
El núcleo UEFI es extremadamente complejo, con millones de líneas de código. Las aplicaciones UEFI están activas después de la descarga. El núcleo se desarrolló sobre el principio de "seguridad a través de la oscuridad".
La especificación es absolutamente una locura si quieres hurgar.
Anillo −3. Motor de control
El anillo más privilegiado. En el caso de Intel (x86), este es el Intel Management Engine. Este sistema puede encender silenciosamente nodos y sobrescribir discos, el núcleo inicia
Minix 3 , así como un servidor web y toda la pila de red. Resulta que gracias a esto, Minix es el sistema operativo de escritorio más popular. El motor de control tiene muchas funciones. Probablemente me llevará un día entero enumerarlos. Si lo desea, hay
muchos recursos para un estudio más detallado.
Entre ring −2 y ring −3 en nuestra pila hay al menos otros dos núcleos y medio, así como un montón de complejidad patentada e innecesaria. Cada uno de estos núcleos tiene sus propias pilas de red y servidores web. El código puede cambiar solo, persistiendo después de apagar y volver a instalar.
Tenemos muy poca información sobre lo que el código realmente hace en estos anillos, lo cual es horrible, dado que estos anillos tienen la mayoría de los privilegios.Todos tienen hazañas
No debería sorprender a nadie que haya vulnerabilidades en los anillos −2 y −3. Cuando se encuentran, es realmente terrible. Solo como ejemplo, aunque puede buscar otros ejemplos usted mismo, hubo
un error en el servidor web Intel Management Engine que el desarrollador no había conocido durante siete años .
¿Cómo se puede mejorar la situación?
NERF: Firmware reducido no extensible
NERF es en lo que está trabajando la comunidad. El objetivo es hacer que el firmware sea menos capaz de hacer daño y hacer que sus acciones sean más visibles. Se esfuerzan por eliminar todos los componentes del tiempo de ejecución, pero esto aún es difícil de hacer en Intel Management Engine. Pero puede eliminar el servidor web y la pila de IP desde allí. Los desarrolladores también desean eliminar la pila de IP UEFI, otros controladores y eliminar la característica de auto-firmware Intel Management / UEFI.
me_cleaner
Proyecto para limpiar Intel Management Engine a la funcionalidad mínima requerida (
en GitHub ).
u-boot y coreboot
u-boot y
coreboot son firmware de código abierto. Manejan la inicialización del chip y la DRAM. Los Chromebook usan ambos, coreboot en x86 y u-boot en el resto. Este es uno de los pasos que
verifican para cargar .
La filosofía de diseño de Coreboot es
"hacer el mínimo necesario para usar el hardware y luego transferir el control a otro programa llamado carga útil " . En este caso, es linuxboot.
linuxboot
Linuxboot maneja los controladores de dispositivos, la pila de red y proporciona un entorno multitarea multiusuario. Está construido en Linux, por lo que un solo núcleo puede ejecutarse en múltiples placas. Linux ya ha sido suficientemente probado y muchas personas siguen el código, ya que es bastante utilizado. Es mejor usar un núcleo abierto con una gran cantidad de "controladores" que otros dos núcleos y medio, diferentes y cerrados. Esto significa que reducimos la superficie de ataque debido a menos variantes de código y confiamos en el código fuente abierto. Linux mejora la confiabilidad de arranque al reemplazar los controladores de firmware mal probados con controladores mejorados de Linux.
Usando el kernel, ya tenemos herramientas de firmware: los desarrolladores pueden usar herramientas conocidas cuando necesitan escribir lógica para verificar firmas, cifrar un disco, etc. Todo esto en un lenguaje moderno, probado, compatible y fácil de leer.
u-root
u-root es el kit de herramientas y gestor de arranque del espacio de usuario de golang. Se usa como initramfs para el kernel de Linux en linuxboot.
Dicen que la pila NERF ha reducido el tiempo de arranque en 20 veces. Pero este es un artículo de seguridad, así que volvamos a la seguridad ...
La pila NERF mejora la visibilidad de muchos componentes que anteriormente eran completamente propietarios. Sin embargo, los dispositivos todavía tienen muchos otros firmware.
¿Qué pasa con otro firmware?
Necesitamos firmware abierto para el controlador de interfaz de red (NIC), unidades de estado sólido (SSD) y controlador de administración básica (BMC).
El proyecto Open Compute está trabajando en el firmware
NIC 3.0 . Será interesante ver lo que hacen.
Hay
OpenBMC y
u-bmc para BMC . Escribí un poco sobre ellos en un
artículo anterior .
Necesitamos tener todo el firmware de código abierto para garantizar una visibilidad completa en la pila y verificar el estado del software en la máquina.
Raíces de confianza
El propósito de la raíz de confianza es verificar que el software apropiado esté instalado en cada componente del equipo. Puede asegurarse de que el equipo no sea pirateado. Como ahora tenemos mucho código fuente cerrado en muchas áreas del equipo, esto es difícil de hacer. ¿Cómo saber realmente que no hay vulnerabilidades o puertas traseras en el firmware del componente? De ninguna manera El código abierto es otra cosa.
Parece que cada nube y cada proveedor ofrecen su propia raíz de confianza. Microsoft tiene
Cerberus , Google tiene
Titan , Amazon tiene
Nitro . Parecen implicar una confianza explícita en el código propietario (código que no vemos). Esto deja un sentimiento extraño.
¿No sería mejor usar código abierto? Luego podemos verificar sin lugar a dudas que el código compilado a partir del código fuente es el mismo que funciona en el equipo donde sea que esté instalado el firmware. Luego podemos verificar que la máquina esté en el estado correcto, sin dudar que sea vulnerable o con una puerta trasera.Esto hace que te preguntes qué pequeños proveedores de la nube, como DigitalOcean o Packet, usan como raíz de la confianza. Lo pregunté en Twitter, pero no obtuve una respuesta decente ...
Hay una gran conferencia de
Paul McMillan y Matt King
sobre la seguridad del equipo al escalar . Los autores describen en detalle cómo proteger el hardware y, al mismo tiempo, brindan a los clientes acceso a él. Cuando reciben el equipo de vuelta de los clientes, deben asegurarse de manera constante y confiable de que todo permanezca sin cambios y que no haya sorpresas ocultas en ningún componente.
Todos los proveedores de la nube deben asegurarse de que el equipo no se vea comprometido después de que el cliente realice los cálculos.
Tolerancia de fallas del firmware de la plataforma
Sin embargo, los fabricantes de chips parecen tener un aspecto especial. Intel tiene
resistencia de firmware de plataforma y Lattice tiene
resistencia de firmware de plataforma . Parecen estar más centrados en las pautas NIST para la
tolerancia a fallas del firmware de la plataforma .
Intenté preguntar en Internet quién lo usó, pero recibí pocas respuestas, así que si usa dispositivos con tecnología de Resistencia de Firmware de Plataforma, ¡hágamelo saber!
De la
conferencia OCP sobre innovaciones en el firmware de Intel, parece que la Plataforma de Resistencia de Firmware (PFR) de Intel y Cerberus van de la mano. Intel usa PFR para implementar los Principios de Certificación Cerberus. Gracias
@msw por la aclaración.
Sería bueno reducir la variedad moteada de herramientas para hacer este trabajo. También me gustaría ver el código fuente para ver por sí mismo que es seguro.
Como ayudar
¡Espero que tenga alguna idea de qué proyectos existen para desarrollar firmware de código abierto y lo importante que es! Si quieres ayudar, díselo a los demás. Intenta usar plataformas de código abierto. Las Chromebooks son un gran ejemplo, así como las computadoras
Purism . Puede preguntar a sus proveedores qué hacen para lanzar firmware de código abierto y garantizar la seguridad de los equipos con una base de confianza. Feliz nerd! :)