Microsoft filtró un «mecanismo maestro» de Secure Boot

¿Recuerdan aquellas ocasiones en las que hablamos sobre Secure Boot? Bueno, de algún modo Redmond dejó escapar ciertas «llaves doradas», que en realidad simbolizan una política especial equivalente a un «modo de desarrollo», y que a su vez desactiva varias de las funciones principales de Secure Boot. ¿La mejor parte? Microsoft pensó que esto no era un problema al principio, pero lanzó dos parches en menos de un mes. ¿Se escapó el genio de la lámpara?

Privacidad, seguridad, código propietario, open source, jailbreaking, rooting… términos que van, vienen, chocan, comparten un camino similar, o se despedazan entre sí. El usuario promedio queda atrapado en una tormenta sin saber qué es lo más conveniente, y los argumentos de todas las partes involucradas se convierten en ruido blanco. La última novedad que acaba de colocarse por arriba de dicho ruido involucra a Secure Boot, viejo conocido aquí en NeoTeo, teórico protector de la integridad del ordenador y su sistema operativo (en este caso específico, varias versiones de Windows), y enemigo mortal de muchos jinetes de Linux que quisieron hacer un «dual-boot» en sus nuevos dispositivos y no lo lograron. Microsoft indicó (en más de una ocasión) que los sistemas certificados basados en x86 deben permitir a Secure Boot entrar en un «modo personalizado» o dar la opción de desactivarlo por completo, aunque eso no se extiende a dispositivos ARM, una de las razones por las que todas esas tablets con Windows RT son en la actualidad poco más que ladrillos. Sin embargo, el estado general de Secure Boot podría cambiar por completo dentro de algunos meses.

¿Qué sucedió con exactitud? Dos expertos en seguridad identificados con los seudónimos MY123 y Slipstream descubrieron algo a lo que han bautizado «llaves doradas», que no son llaves digitales en el sentido tradicional, sino una política especial de Secure Boot que modifica las tareas ejecutadas por UEFI al inicio… entre las que se encuentra el chequeo de firmas. Al parecer, esta política existe como un «modo de desarrollo» o «modo debug» si así lo prefieren, el cual habilita a los programadores a evaluar nuevos builds, detectar bugs y aplicar las correcciones necesarias sin tener que firmar todo. ¿Cómo llegó a manos de MY123 y Slipstream? Básicamente la encontraron a fines de marzo «dormida» en dispositivos que Microsoft ofrece a la venta. Se contactaron con la compañía en abril, y en ese entonces Microsoft consideró que no era un riesgo de seguridad (requiere acceso físico «o» privilegios de administrador), pero entre junio y julio decidieron pagar una recompensa y lanzar dos parches, MS16-094 y MS16-100, que si bien logran mitigar la situación, no presentan una solución definitiva.

¿En qué se transformará esto? La respuesta es «depende». La política podría permitir la instalación de sistemas operativos alternativos sobre dispositivos con Windows RT (sin los hotfixes antes mencionados) o Windows Phone. En lo personal me gustaría ver qué puede hacer la comunidad (no será nada sencillo, aunque hay genios allá afuera que viven buscando desafíos de este tipo), pero la moneda tiene dos caras. No es lógico crear una lista negra con cada «bootmgr» afectado porque quebraría la compatibilidad en más de un caso (discos originales de instalación, particiones de rescate, respaldos, etc.), y si alguien aprovecha esta brecha para instalar un «paquete» malicioso, bueno…

(N. del R.: Si, la página oficial se parece a un cracktro de los ’90)