{"id":119554,"date":"2024-08-21T09:43:00","date_gmt":"2024-08-21T07:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot"},"modified":"2024-08-21T09:43:00","modified_gmt":"2024-08-21T07:43:00","slug":"oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","title":{"rendered":"An error in the Windows update blocked the boot of Linux when using UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In an update released by Microsoft on Tuesday, a problem has been identified that prevents the loading of Linux systems installed alongside Windows on the same computer. The issue stems from a fix aimed at addressing an old vulnerability (CVE-2022-2601) in the GRUB bootloader, which was patched in 2022. Microsoft has not yet issued any statements regarding the failure or commented on it. <\/p>\n
The release note indicated that the fix implementing the new SBAT (UEFI Secure Boot Advanced Targeting) policy would apply to systems running only Windows and would not affect dual-boot configurations (the change blocked the use of boot images with the old GRUB to bypass Secure Boot on systems with only Windows installed). It was also noted that the change could cause issues with loading ISO images of older systems that were shipped with a vulnerable version of GRUB. In practice, problems have also occurred for users of dual-boot systems using new Linux distributions, such as Ubuntu 24.04 and Debian 12.6, in which the GRUB vulnerability has long been fixed. <\/p>\n
The problem manifests as a halt in the loading process with the message 'Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation.' To restore functionality, it is recommended to remove the installed SBAT data in UEFI by disabling Secure Boot in the firmware, booting from a fresh Linux distribution that supports UEFI Secure Boot, such as Ubuntu, executing the command 'mokutil --set-sbat-policy delete' in the console, and then rebooting the Linux distribution to set the correct SBAT policy. After this, Secure Boot can be re-enabled in the firmware. <\/p>\n
The SBAT mechanism was developed by Red Hat in collaboration with Microsoft to block vulnerabilities in the GRUB bootloader and the shim layer without revoking the digital signature. SBAT involves adding metadata to the executable files of UEFI components, which includes information about the manufacturer, product, component, and version. The specified metadata is digitally signed and can be separately included in the lists of allowed or disallowed components for UEFI Secure Boot. SBAT allows for blocking the use of digital signatures for specific component version numbers without the need to revoke keys for Secure Boot. <\/p>\n
Blocking vulnerabilities through SBAT does not require the use of the UEFI revocation certificate list (dbx), and is performed at the level of replacing the internal key for signature generation and updating GRUB2, shim, and other boot artifacts supplied by distributions. Before the introduction of SBAT, updating the revoked certificate list (dbx, UEFI Revocation List) was a mandatory condition for complete vulnerability blocking, as an attacker, regardless of the operating system used, could compromise UEFI Secure Boot using a boot medium with an old vulnerable version of GRUB2 that was signed with a digital signature. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"