MS leaked the "golden keys" that unlock Windows-powered devices sealed by Secure Boot | |
Anonymous Coward User ID: 70837898 Finland 08/11/2016 08:21 AM Report Abusive Post Report Copyright Violation | |
Anonymous Coward User ID: 63444365 United States 08/11/2016 08:23 AM Report Abusive Post Report Copyright Violation | |
Anonymous Coward (OP) User ID: 69844010 United Kingdom 08/11/2016 08:33 AM Report Abusive Post Report Copyright Violation | So, does it mean I can install Linux on Secure Boot systems that came with a pre-installed Windows 10? ------------------------------------------------- I would think it will work for Windows 10 machines! - Details: The policy is universal; it is not tied to any particular architecture or device. It works on x86 and ARM, on anything that uses the Windows boot manager. Technically speaking, it is a supplemental policy: it's supposed to be merged with other Secure Boot policies, but you can use it as a main policy to switch off signature checks. [link to rol.im (secure)] ... During the development of Windows 10 v1607 'Redstone', MS added a new type of secure boot policy. Namely, "supplemental" policies that are located in the EFIESP partition (rather than in a UEFI variable), and have their settings merged in, dependant on conditions (namely, that a certain "activation" policy is also in existance, and has been loaded in). Redstone's bootmgr.efi loads "legacy" policies (namely, a policy from UEFI variables) first. At a certain time in redstone dev, it did not do any further checks beyond signature / deviceID checks. (This has now changed, but see how the change is stupid) After loading the "legacy" policy, or a base policy from EFIESP partition, it then loads, checks and merges in the supplemental policies. See the issue here? If not, let me spell it out to you plain and clear. The "supplemental" policy contains new elements, for the merging conditions. These conditions are (well, at one time) unchecked by bootmgr when loading a legacy policy. And bootmgr of win10 v1511 and earlier certainly doesn't know about them. To those bootmgrs, it has just loaded in a perfectly valid, signed policy. The "supplemental" policy does NOT contain a DeviceID. And, because they were meant to be merged into a base policy, they don't contain any BCD rules either, which means that if they are loaded, you can enable testsigning. Not just for windows (to load unsigned driver, ie rootkit), but for the {bootmgr} element as well, which allows bootmgr to run what is effectively an unsigned .efi (ie bootkit)!!! (In practise, the .efi file must be signed, but it can be self-signed) You can see how this is very bad!! A backdoor, which MS put in to secure boot because they decided to not let the user turn it off in certain devices, allows for secure boot to be disabled everywhere! |
Anonymous Coward User ID: 70438231 United States 08/11/2016 08:36 AM Report Abusive Post Report Copyright Violation | |