{"id":112924,"date":"2024-01-15T17:28:03","date_gmt":"2024-01-15T15:28:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-patchah-red-hat-k-zagruzchiku-grub2-pozvolyayushhaya-obojti-proverku-parolya"},"modified":"2024-01-15T17:28:03","modified_gmt":"2024-01-15T15:28:03","slug":"uyazvimost-v-patchah-red-hat-k-zagruzchiku-grub2-pozvolyayushhaya-obojti-proverku-parolya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/news\/uyazvimost-v-patchah-red-hat-k-zagruzchiku-grub2-pozvolyayushhaya-obojti-proverku-parolya","title":{"rendered":"S\u00e5rbarhed i Red Hat-patchene til GRUB2-bootloaderen, der muligg\u00f8r omg\u00e5else af adgangskodekontrollen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Oplysninger om s\u00e5rbarheden (CVE-2023-4001) i patchene til GRUB2-bootsystemet, forberedt af Red Hat, er blevet offentliggjort. S\u00e5rbarheden g\u00f8r det muligt p\u00e5 mange systemer med UEFI at omg\u00e5 adgangskoden, der er indstillet i GRUB2 for at begr\u00e6nse adgangen til bootmenuen eller kommando-linjen for bootloaderen. S\u00e5rbarheden skyldes en \u00e6ndring, der er tilf\u00f8jet af Red Hat i GRUB2-pakken, der leveres med RHEL og Fedora Linux. Problemet manifesterer sig ikke i det prim\u00e6re GRUB2-projekt og p\u00e5virker kun distributioner, der har anvendt yderligere patches fra Red Hat. <\/p>\n
Problemet skyldes en fejl i logikken for brugen af UUID til at finde en enhedsl\u00e6ser med konfigurationsfilen (f.eks. \"\/boot\/efi\/EFI\/fedora\/grub.cfg\"), der indeholder en hash af adgangskoden. For at omg\u00e5 godkendelsen kan en bruger med fysisk adgang til computeren tilslutte et eksternt drev, s\u00e5som et USB-flashdrev, og indstille det til at have et UUID, der matcher identifikatoren for bootpartitionen \/boot p\u00e5 det angrebne system. <\/p>\n
Mange UEFI-systemer h\u00e5ndterer hovedsageligt eksterne drev f\u00f8rst og placerer dem i listen over opdagede enheder f\u00f8r station\u00e6re drev, s\u00e5ledes at partitionen \/boot, der er forberedt af angriberen, prioriteres ved behandling, og i overensstemmelse hermed vil GRUB2 fors\u00f8ge at indl\u00e6se konfigurationsfilen fra denne partition. Under s\u00f8gningen efter partitionen ved hj\u00e6lp af kommandoen \"search\" i GRUB2 fastsl\u00e5s kun det f\u00f8rste matchende UUID, hvorefter s\u00f8gningen stopper. Hvis hovedkonfigurationsfilen ikke findes p\u00e5 en given partition, vil GRUB2 vise et kommandoprompt, der giver kontrol over den videre indl\u00e6sningsproces. <\/p>\n
For at bestemme UUID for partitionen kan en lokal, ikke-privilegeret bruger bruge v\u00e6rkt\u00f8jet \"lsblk\", men en uvedkommende bruger uden adgang til systemet, men som kan observere opstartsprocessen, kan i nogle distributioner identificere UUID fra de diagnostiske meddelelser, der vises under opstarten. S\u00e5rbarheden er rettet af Red Hat ved at tilf\u00f8je et nyt argument til \"search\"-kommandoen, der begr\u00e6nser scanning af UUID til kun de blokkerede enheder, der bruges til at starte bootloaderen (dvs. partitionen \/boot skal kun v\u00e6re p\u00e5 den samme disk som systempartitionen EFI). \n Kilde: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"