Protección de puerta trasera de firmware

6

enlace

  

El fundador de Ubuntu Linux, Mark Shuttleworth, ha comparado el ACPI con el troyano   caballos [28] Ha descrito el firmware propietario (firmware ACPI o   cualquier otro firmware) como un riesgo de seguridad, diciendo que el "firmware en su   dispositivo es el mejor amigo de la NSA "y firmware de llamada (ACPI o   no ACPI) un caballo de Troya de proporciones monumentales ". Ha señalado   que el firmware de código cerrado y de baja calidad es una amenaza importante para   seguridad del sistema: [7] "Su mayor error es asumir que la NSA es   la única institución que abusa de esta posición de confianza - de hecho, es   Es razonable suponer que todo el firmware es un pozo de inseguridad,   cortesía de incompetencia del más alto grado de los fabricantes, y   competencia del más alto grado a partir de una amplia gama de tales   agencias ".

     

Como solución a este problema, ha pedido un firmware declarativo.   (ACPI o no ACPI). [7] El firmware debe ser de código abierto para que el código   Puede ser revisado y verificado. El firmware debe ser declarativo, es decir,   que debe describir "vinculación de hardware y dependencias" y debe   No incluye código ejecutable.

¿Hay alguna forma de protegerse adecuadamente de las puertas traseras en el ACPI o en general?

¿Se puede infectar o inyectar el firmware con puertas traseras o troyanos muy fácilmente?

    
pregunta Jason 24.06.2014 - 14:39
fuente

1 respuesta

6

El firmware es el código. Se ejecuta en la CPU en nombre de algún dispositivo de hardware; o se ejecuta directamente en el dispositivo.

En general, si su propio hardware tiene la intención de espiarle, pierde. Un desarrollo más preocupante es que muchas piezas de hardware (p. Ej., Teclados) contienen un firmware completamente honesto que es actualizable , y se ha detectado algún malware en su hábitat natural que reemplaza algunos firmwares (utilizando la función "actualizable") ) con código malicioso.

El firmware más grande de todos se llama BIOS ; es el código que se ejecuta primero cuando se inicia la computadora, antes de que se cargue el sistema operativo (y, de hecho, el BIOS es responsable de cargar el sistema operativo). El software malicioso instalado en el BIOS mismo resiste, por definición, el reformateo y reinstalación completos del sistema operativo. El virus CIH , más conocido como "virus de Chernobyl", ya estaba enredado con el BIOS en 1998 ( pero lo estaba haciendo de manera bastante inexperta, resultando en una BIOS mutilada, no en una BIOS infectada sigilosamente). Los virus más recientes se instalarán de forma no destructiva y persistirán.

El BIOS no es la única pieza de firmware recargable en una computadora, por lo que las posibilidades son grandes.

Para escribir un virus instalable en el firmware, debe realizar ingeniería inversa en el formato de hardware y firmware. Parece que los atacantes hacen eso. Los firmwares de código abierto técnicamente harían más fácil la ingeniería inversa, pero también ayudarían a los "defensores" que buscan vulnerabilidades de seguridad que puedan solucionar. Es el clásico debate de seguridad de fuente abierta / fuente cerrada que ha estado en curso durante bastante tiempo y no ha llegado a cualquier tipo de conclusión definitiva todavía.

Sin embargo, la llamada para "firmware sólo declarativo" es un poco errónea. La idea es que ninguna pieza de hardware debe venir con un código específico para ser ejecutado en la CPU; en su lugar, dicho código debe estar en el controlador del sistema operativo. Esto no tiene en cuenta toda la situación de dos maneras principales:

  • Una máquina debe poder iniciarse para cargar realmente el sistema operativo y los controladores, por lo que aún debe haber algún firmware en algún lugar (a saber, el BIOS) que sepa cómo acceder al disco duro.

  • Muchos dispositivos periféricos tienen su propia CPU. Esto incluye, por supuesto, GPU, pero todas las interfaces de red, teclados ... y, para ellos, no tiene ningún sentido pedir un "firmware declarativo solamente" ya que el código está destinado a la CPU del dispositivo de todos modos, no a la principal CPU, y el sistema operativo nunca lo ve. Se ha demostrado un keylogger insertado en el firmware para un teclado Apple .

Soluciones genéricas:

  • Trabaje solo con hardware de "fuentes confiables" con procedimientos de seguridad internos estrictos (en particular, la verificación de antecedentes de los empleados) de modo que sea posible que el firmware sea inicialmente limpio y honesto.

  • Hágalo de manera que el firmware no sea recargable. De nuevo, esto depende del hardware. Por ejemplo, para algunas placas base, la BIOS no se puede volver a flashear a menos que se configure físicamente un puente específico; de lo contrario, la corriente de actualización necesaria simplemente no podrá alcanzar el chip.

Dado que una gran cantidad de hardware existente con firmware recargable no se puede hacer no recargable, y las "fuentes confiables" son una rareza desde el punto de vista de cualquier nación (porque las piezas provienen de diferentes países), se deduce que estas soluciones genéricas no son realmente prácticos.

(Tal vez China pueda crear una "computadora 100% china" pero tener todas las piezas producidas en su territorio nacional no es lo mismo que poder confiar en su honestidad y confiabilidad.)

    
respondido por el Tom Leek 24.06.2014 - 15:18
fuente

Lea otras preguntas en las etiquetas