{"id":99320,"date":"2021-03-03T16:22:39","date_gmt":"2021-03-03T14:22:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2021-03-03T16:22:39","modified_gmt":"2021-03-03T14:22:39","slug":"trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/news\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Sv\u00e5rt \u00e5tg\u00e4rdliga s\u00e5rbarheter i GRUB2 som m\u00f6jligg\u00f6r omg\u00e5enden av UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Information about 8 vulnerabilities in the GRUB2 bootloader has been revealed, allowing bypassing the UEFI Secure Boot mechanism and enabling the execution of unverified code, such as introducing malware that operates at the bootloader or kernel level. <\/p>\n

Recall that in most Linux distributions, a small shim layer, certified by Microsoft's digital signature, is used for verified loading in UEFI Secure Boot mode. This layer verifies GRUB2 with its own certificate, allowing distribution developers not to certify every kernel and GRUB update with Microsoft. Vulnerabilities in GRUB2 allow code execution at the stage after successful verification of the shim, but before the operating system loads, inserting itself into the trust chain while Secure Boot is active and gaining full control over the subsequent boot process, including loading another OS, modifying operating system components, and bypassing Lockdown protection. <\/p>\n

As with last year's BootHole vulnerability, it is insufficient to just update the bootloader to block the problem, as an attacker, regardless of the operating system used, can compromise UEFI Secure Boot using a bootable medium with an old vulnerable version of GRUB2, certified by a digital signature. The issue can only be resolved by updating the list of revoked certificates (dbx, UEFI Revocation List), but in this case, the ability to use old installation media with Linux will be lost. <\/p>\n

On systems with firmware that has updated the list of revoked certificates, in UEFI Secure Boot mode, only updated builds of Linux distributions will be able to load. Distributions will need to update their installers, bootloaders, kernel packages, fwupd firmware, and the shim layer, generating new digital signatures for them. Users will have to update installation images and other boot media, as well as load the list of revoked certificates (dbx) into the UEFI firmware. Until the dbx is updated in UEFI, the system remains vulnerable regardless of updates installed in the OS. The status of vulnerability remediation can be assessed on these pages: Ubuntu, SUSE, RHEL, Debian. <\/p>\n

F\u00f6r att \u00e5tg\u00e4rda problem som uppst\u00e5r vid spridning av \u00e5terkallade certifikat planeras det att i framtiden anv\u00e4nda mekanismen SBAT (UEFI Secure Boot Advanced Targeting), vars st\u00f6d har implementerats f\u00f6r GRUB2, shim och fwupd, och som fr\u00e5n och med de kommande uppdateringarna kommer att anv\u00e4ndas ist\u00e4llet f\u00f6r funktionaliteten som tillhandah\u00e5lls av paketet dbxtool. SBAT har utvecklats i samarbete med Microsoft och inneb\u00e4r att nya metadata, som inkluderar information om tillverkare, produkt, komponent och version, l\u00e4ggs till i exekverbara filer av UEFI-komponenter. De angivna metadatan signerades digitalt och kan dessutom inkluderas i listor \u00f6ver godk\u00e4nda eller blockerade komponenter f\u00f6r UEFI Secure Boot. P\u00e5 s\u00e5 s\u00e4tt kommer SBAT att m\u00f6jligg\u00f6ra manipulation av versionsnummer f\u00f6r komponenter vid en \u00e5terkallelse, utan behov av att regenerera nycklar f\u00f6r Secure Boot och utan att skapa nya signaturer f\u00f6r k\u00e4rnan, shim, grub2 och fwupd. <\/p>\n

Uppt\u00e4ckta s\u00e5rbarheter: <\/p>\n