UEFI Dual-Boot with Windows 10 -- latest update from Redmond seems to have a UEFI security issue

A German news-ticker is reporting that, the latest Windows 10 (Anniversary) update has a UEFI security issue: with administrator privileges it is possible to disable the UEFI Secure-Boot feature from the Windows 10 User Interface and, enable any possible operating system component provided, that the component has a key signature – any key signature. <https://technet.microsoft.com/en-us/library/security/ms16-094>

US American Microsoft news-tickers are not (yet) reporting this issue: <http://www.infoworld.com/blog/woody-on-windows/> <https://www.askwoody.com/>
Microsoft’s Developer Network only mentions that “RT” devices need UEFI Secure-Boot: <https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/disabling-secure-boot>
[HR][/HR]For normal Desktop PCs probably not so interesting (apart from any “knock-on” issues which “accidentally” kill the Dual-Boot) but, for Surface Tablets and Windows Phones this could be quite interesting: disable Secure-Boot by means of the Windows 10 “Anniversary” version and install Linux (of course openSUSE . . . ) >:)

Take a look at this

Secure Boot Isn’t So Secure After All: The Golden Key Is Out


Secure boot is dubious security even when it works since anyone that can mod the boot stack already owns you.

As I understand it, this is mainly a Windows bug.

The primary concern is for harware where secure-boot cannot be disabled. The Windows bug allows one to bypass secure-boot anyway. Apparently they accidentally shipped some debugging tools which should have been removed from the released version.

I don’t see it as a particular problem for linux users, many of whom disable secure-boot anyway.

For myself – I leave secure-boot enabled. But I don’t think it adds any real security to my system. I leave it enabled mainly so that I can spot problems in the opensuse support for secure-boot.

If I read it correctly - some files that were intended for newer versions of bootloader are misinterpreted by older versions allowing to bypass strict signature checks. This is really tough situation, because the only way to fix it from Microsoft side is to blacklist all versions of misbehaving bootloaders while at the same time providing updated installation media. And even then blacklisting will only work if systems in question are connected to Internet and are running Windows in the first place.

I see no true security advantage to UEFI or secure boot. I just disable it altogether.

The Linux Foundation has published this paper with explaining the UEFI issue:
Bruce Schneier in his latest CRYPTO-GRAM Newsletter has the following URLs:
<http://www.theregister.co.uk/2016/08/10/microsoft_secure_boot_ms16_100/> [Which points to this URL: <https://blogs.technet.microsoft.com/dubaisec/2016/03/14/diving-into-secure-boot/>] >:)