Hard Light Productions Forums
Off-Topic Discussion => General Discussion => Topic started by: S-99 on August 10, 2016, 08:21:23 pm
-
Found here. (http://www.theregister.co.uk/2016/08/10/microsoft_secure_boot_ms16_100/)
when Secure Boot is fully enabled in the firmware of a Microsoft device, it will only boot up an operating system that is cryptographically signed by Redmond. That stops you from booting up any OS you want on your Windows RT tablet, certain Windows Phones and so on.
Alongside this, there are Secure Boot policies, which are rules that are loaded and obeyed during early startup by the Windows boot manager. These policies must also be signed by Microsoft to be accepted, and are installed on devices and machines using a Microsoft-signed tool.
For internal debugging purposes, Microsoft created and signed a special Secure Boot policy that disables the operating system signature checks, presumably to allow programmers to boot and test fresh OS builds without having to sign each one.
If you provision this magic policy, that is, if you install it into your firmware, the Windows boot manager will not verify that it is booting an official Microsoft-signed operating system. It will boot anything you give it provided it is cryptographically signed, even a self-signed binary – like a shim that loads a Linux kernel.
Aside from the obvious idea of security through obscurity and the other implications of this leak and other systems with backdoors that only say government or law enforcement are meant to know about... this is good news since the future of locked devices by secure boot is now back in the control of the consumer for now.
The two researchers noted in the article (MY123 and Slipstream) findings posted here (https://rol.im/securegoldenkeyboot/) (beware interesting graphics).
-
It's already been partially patched and will be completely patched come next patch tuesday (aka a month from now)
-
It's already been partially patched and will be completely patched come next patch tuesday (aka a month from now)
I heard the patch didn't work. Did they make a more successful patch?
-
http://arstechnica.com/security/2016/08/microsoft-secure-boot-firmware-snafu-leaks-golden-key/
At first, Microsoft apparently dismissed the find as a non-issue, before changing its mind, and then slowly applying a patch. The software giant eventually awarded a bug bounty in June, and has since released two patches—MS16-094 and MS16-100—with a third on the way. It's understood that none of them are able to directly shut the back door, and there's a distinct possibility that the hole opened by the golden keys may not be truly closable.
According to the researchers, "it'd be impossible in practise for MS to revoke every bootmgr earlier than a certain point, as they'd break install media, recovery partitions, backups, etc."
-
It's already been partially patched and will be completely patched come next patch tuesday (aka a month from now)
More on that...
Either way, it'd be impossible in practise for MS to revoke every bootmgr earlier than a certain point, as they'd break install media, recovery partitions, backups, etc. - RoL disclosure timeline: ~march-april 2016 - found initial policy, contacted MSRC ~april 2016 - MSRC reply: wontfix, started analysis and reversing, working on almost-silent (3 reboots needed) PoC for possible emfcamp demonstration ~june-july 2016 - MSRC reply again, finally realising: bug bounty awarded july 2016 - initial fix - fix analysed, deemed inadequate. reversed later rs1 bootmgr, noticed additional inadequate mitigation august 2016 - mini-talk about the issue at emfcamp, second fix, full writeup release
Found here (https://rol.im/securegoldenkeyboot/).
-
more technical writeups need to be in this format :)