Remember when we talked about Secure Boot? Well, somehow Microsoft let slip some "golden keys" that actually represent a special policy equivalent to a "development mode", which in turn disables several core Secure Boot functions. The best part? Microsoft initially thought this was not a problem at first, but released two patches in less than a month. Did the genie escape the lamp?
Privacy, security, proprietary code, open source, jailbreaking, rooting... terms that come, go, clash, share a similar path, or tear each other apart. The average user is caught in a storm without knowing what is most convenient, and the arguments from all involved parties become white noise. The latest news that just rose above that noise involves Secure Boot, a familiar name here at NeoTeo, the theoretical protector of your computer's integrity and its operating system (in this specific case, several versions of Windows), and the mortal enemy of many Linux enthusiasts who wanted to set up a "dual-boot" on their new devices and failed. Microsoft stated (more than once) that certified systems based on x86 must allow Secure Boot to enter a "custom mode" or give the option to turn it off completely, although that does not extend to ARM devices, one of the reasons why all those Windows RT tablets are now little more than bricks. However, the general state of Secure Boot could change completely within a few months.
What exactly happened? Two security experts using the pseudonyms MY123 and Slipstream discovered something they have dubbed "golden keys", which are not digital keys in the traditional sense, but a special Secure Boot policy that modifies the tasks executed by UEFI at startup, including the signature check. Apparently, this policy exists as a "development mode" or "debug mode", if you prefer, which allows programmers to evaluate new builds, detect bugs and apply necessary fixes without having to sign everything. How did it end up in the hands of MY123 and Slipstream? Basically, they found it at the end of March "dormant" on devices Microsoft offers for sale. They contacted the company in April, and at that time Microsoft considered it was not a security risk (it requires physical access 'or' administrator privileges), but between June and July they decided to pay a reward and release two patches, MS16-094 and MS16-100, which, while mitigating the situation, do not provide a definitive solution.
What will this become? The answer is "it depends". The policy could allow the installation of alternative operating systems on devices with Windows RT (without the aforementioned hotfixes) or Windows Phone. Personally, I would like to see what the community can do (it won't be easy, although there are geniuses out there always looking for challenges like this), but the coin has two sides. It is not logical to create a blacklist of every affected "bootmgr" because it would break compatibility in more than one case (original installation discs, rescue partitions, backups, etc.), and if someone takes advantage of this gap to install a malicious "package", well...
(Editor's note: Yes, the official page looks like a cracktro from the '90s)
