Hace 5 horas | Por ccguy a arstechnica.com
Publicado hace 5 horas por ccguy a arstechnica.com

Investigadores de la empresa de seguridad Binarly revelaron que Secure Boot está completamente comprometido en más de 200 modelos de dispositivos vendidos por Acer, Dell, Gigabyte, Intel y Supermicro. La causa: una clave criptográfica en la que se basa Secure Boot en esos modelos que se vio comprometida en 2022. En un repositorio público de GitHub comprometido en diciembre de ese año, alguien que trabajaba para varios fabricantes de dispositivos con sede en EE.UU. publicó lo que se conoce como clave de plataforma.

Comentarios

chemado_chema

#1 ano-nadado

f

#1 lo que tendrías que estar, mas que anonadado, es avergonzado por hablar de manera tan vehemente sin tener (obviamente) mucha idea del tema.

WcPC

#6 La de problemas que he tendido cuando implementaron esa mierda en placas para instalar Linux...
En algunas placas era fácil de desactivar, en otras no, sobre todo al principio.
Pero si, no sé demasiado.
Dejé de trabajar profesionalmente en el tema hace más de una década.

frg

#7 Endonces ni siquiera has mirado como se dificulta la carga de kernels y módulos no firmados gracias a Secure Boot en los Linux actuales, o como te puede proteger de la instalación de ciertas utilidades por parte de terceros ...

WcPC

#8 Si, claro.
Pero la razón de la rápida introducción fue ese, entorpecer el despliegue de sistemas operativos alternativos a Windows y la dificultad de que puedas tener multiboot...
A ver, que no te pueden vender una cadena para atarte a Windows como eso, tienen que darte algo más y justificarlo.
Edito: #10 La última línea la he escrito mientras tu escribías y creo que vale como respuesta.

M

#6 Hay otras formas de dificultar que se arranque con otro sistema operativo "no oficial" sin tocar las narices. Linus Torvalds no está (o al menos no estaba) a favor de ese modelo y es totalmente comprensible.

Luego: https://www.muycomputer.com/2022/07/08/thinkpad-z13-z16-no-linux-secure-boot/

Por mucho que Microsoft "colabore" con el software libre o incluso haya integrado el WSL desde W10 no significa que se haya hecho amigo, esto huele a estrategia. No olvidemos que, tras esto, algunas búsquedas sobre GNU/Linux que solicitamos acaban por esta razón en Microsoft (con un modelo de negocio a las antípodas de GNU) y en posiciones bien altas.

#7 Entrando en las UEFI se puede desactivar sin problema (en principio), no recuerdo tocar alguna máquina que no incluya ese parámetro. Afea en máquinas de empresa, por si quisieras arrancar otra cosa aún con el permiso de esta.

El problema podría estar en que si por algún motivo te cargas el Secure Boot y luego lo reactivas no puedas arrancar la máquina aunque esto lo intenté una vez y pude volver a arrancarlo en una máquina. Ahora bien, no sé de dónde saqué que haciendo eso podrías dejar de arrancar el Windows porque la clave maestra podría cambiar (creo que hay una opción para ello) y tampoco era momento para "pruebas". Y como Windows hace tanto que me da aspereza para probar nada...

No obstante tu comentario en #1 se interpreta correctamente, no te preocupes.

Edito: como dice #10 Secure Boot estaba "bien" por ese motivo, ahora insisto en que eso no debería ser motivo para entrar de esa manera y exigir a fabricantes su implementación para mantenerse con ellos.

WcPC

#13 Gracias por la última línea, ya pensaba que el comentario era demasiado corto, no ofrecía contexto y no se entendía.

f

#13 Que Microsoft, con Pluton, pretenda evitar que en esa maquina se ejecute cualquier otra cosa que no sea windows... mientras esté bien anunciado, no es un problema. Es como si te compras un coche de combustion interna y pretendes ponerle gasolina; no va a funcionar porque no está diseñado para eso.

El SB pretende evitar que se arranque con kernels que pueden haber sido manipulados. Que tendrá sus problemas? Por supuesto: Yo me estoy generando las UKI para mis sistemas y he tenido que poner un par de scripts que eviten que el sistema quede corrompido si algo ocurre enmedio del proceso. Pero que vaya... estos problemas (o similares) los tenía antes tambien, de manera que no es una molestia añadida.

El problema es que, cuando hablais de "no oficial", el que lo lea sin saber de qué hablais va a leer "que no sea windows"... y eso es falso. Tu te puedes generar tus MOK y firmar tus kernels, imagenes de kernel, etc., y dormir mucho mas tranquilo con SB (uses o no windows).

M

#15 "mientras esté bien anunciado, no es un problema"

¿Sabes cuánta gente "inexperta" cae en esta trampa? ¿Conoces a alguien que se haya leído todos los documentos técnicos para, efectivamente, contrastar algo para que no pueda en un futuro inmediato de rebeldía tecnológica no tenga problemas para reemplazar el sistema instalado?

Y no sé por qué digo "inexperta" porque algunos, aún con experiencia, podríamos fiarnos y luego cagarnos en todo.

f

#17 Que no es una trampa: Si resulta que has comprado algo en base a publicidad engañosa, devuelves el cacharro y listo (o lo denuncias si lo crees conveniente). A mi tambien me ha pasado que he comprado sistemas que pensaba que tenían una funcionalidades y resultaba que no, y me he quejado y lo he devuelto, y no hay mas problema.

M

#19 La documentación es tediosa. No es sencillo ni para alguien incluso con cierta experiencia o teniendo al alcance un procedimiento para la incorporación de dichas claves, ya que aún a día de hoy no queda del todo claro. Si alguien con conocimientos termina por deshabilitar dicha función, quien lo compra para trabajar en lo suyo, vé que le funciona y se conforma ya ni hablamos. Si más adelante el conformado se harta del sistema que tiene lo va a tener en cierto modo algo más complicadillo, si no es "deshabilitando" la funcionalidad o cabreándose con algún coprocesador interno que le bloquea.

f

#7 Hombre, pues empieza por ahi. Me atrevo a decir que en las placas actuales se desactiva de manera simple (en las que me he encontrado yo, almenos), y el objetivo no es joder desarrollos "no oficiales" sino asegurar que lo que cargas durante el proceso de arranque no ha sido manipulado. Si que es cierto que durante los primeros dias los kernels de linux no venian firmados (de hecho, es aún el caso en bastantes distribuciones) pero en la mayoría de distribuciones grandes eso ya no es así. Ademas, hay la posibilidad de usar Machine Owner Keys, que son certificados adicionales que el propietario de la maquina puede generar, de manera que puede firmar kernels, loaders, etc., con las correspondientes claves privadas (lo que te sirve para firmarte tu los kernels, imagenes de kernel universales, etc.).

Por supuesto que tiene sus problemas (como todo) pero, en general.... yo lo llevo usando desde hace años, como parte de mi sistema de cifrado de disco completo con arranque medido (de manera que si secure boot no está activado y el sistema está en un estado conocido, el TPM no va a soltar la clave de cifrado) y.... cero problemas.

M

#12 "y el objetivo no es joder desarrollos "no oficiales" sino asegurar que (...)"

Claro que no. ¿Por qué Microsoft quisiera evitar que la gente arrancara el Ubuntu, o el Linux Mint (que llevaba poco tiempo y ya era muy bien visto), que se estaban expandiendo poco a poco como un soplo de aire fresco en todo el mundo con unas soluciones de seguridad que no tienen nada que ver consigo y con unas licencias mucho más favorables a los intereses del ciudadano, por su transparencia y facilidad de modificación?

De 2008: "El pingüino de ‘Linux’ quiere colarse en el ordenador"
https://www.expansion.com/2008/10/17/empresas/tecnologia/1224233969.html

f

#16 Vale, cuéntame: Qué soluciones ha puesto linux sobre la mesa que eviten el arranque del sistema con kernels comprometidos? Me refiero, incluso, a kernels que vienen de unidades externas (como USB). Pues claro que le fué bien a Microsoft que, como efecto colateral, se dificultara el arranque de ubuntu. Pero que el primer laptop con SB habilitado aparecio en el mercado a mediados de octubre-2012, y el primer Fedora con kernel firmado aparecio en Enero-2013. Vamos... que ya querría yo que se respondiera tan rapido cuando hay algun problema con un driver de GPU, cuando esta no es mainstream.

M

#18 Pero Flixter, que ese es el problema, no debemos depender única y exclusivamente del sistema operativo. Si ese sistema arranca es porque nosotros lo hemos permitido, y si el sistema no se ha autoprotegido lo suficiente es problema tanto de este como del usuario o administrador que no se han enterado.

No podemos depender de que un sistema operativo nos facilite la vida en todo su conjunto (tecnológico), y mucho menos si es privativo.

f

#20 Primero: el Secure Boot no es privativo, y segundo: lo que estas diciendo es equivalente a "No vamos a usar HTTPS porque no podemos depender de que un cifrado de transporte nos facilite la vida en términos de confidencialidad y integridad. Es responsabilidad de la aplicación que está enviando datos asegurar esas propiedades."

Yo puedo entender que me digas "Esto es una tecnología introducida por Microsoft, por lo que mi primera reacción es de no fiarme en absoluto". Pero el caso está en que a dia de hoy no hay ninguna tecnologia que impida que un tipo enchufe un USB que se ha encontrado en un parking, conteniendo un vector de ataque tipo rootkit, malware, etc., a parte de SB. O yo la desconozco, vaya.

M

#21 Es que no me fío de Microsoft, no tengo ningún problema en reconocerlo. La transparencia del código que ejecuto para mí es primordial y luego está, cómo no, que el sistema no telemetrice tu máquina y envíe resultados al exterior, ni te infle a "bloatwares". https://www.diarioabierto.es/464306/holanda-detecta-una-posible-vulneracion-de-las-reglas-de-privacidad-por-parte-de-microsoft

Luego, no tiene nada que ver el Secure Boot con HTTPS. Y reconozco que el modelo no es malo, sólo que efectivamente no se documentó lo suficiente y dejó fuera de juego el arranque de sistemas operativos que podrían estar en auge en un momento delicado para la gigante tecnológica (como Windows Vista o Windows . Si se estropea no arrancas, vale, pero tampoco quedan garantías de que no vaya a ser perjudicado por algún otro malware de millones que existen y ya se ha visto en numerosas ocasiones, que "problemas haylos". Esto sólo es uno más, pero muy tocanarices para los usuarios e incluso administradores.

Y ahora no las tengo en que si actualizas esas claves puedas volver al sistema anterior. Ubuntu esto lo automatiza bastante, ahora bien, ¿qué controlas tú?

M

#21 #23 (Windows Vista o Windows "8", que parece que 8 y paréntesis dibuja una cara con gafas...)

frg

#1 Tiene alguna que otra utilidad más, "alguna que otra"

Magankie

Era cuestión de tiempo. Éste tipo de claves termina siempre saliendo.

s

#2 Lo que pasa cuando echas al programador senior de la empresa porque tienes que cumplir con la cuota de despido y les tocó a los mas viejos de la empresa.

Magankie

#4 me he tenido que comer trabajo de senior cuando era junior por ese mismo motivo. Todo lo malo que les pase a las compañías pornese tipo de decisiones me parece poco.