Luka w GRUB2 umożliwiała ominięcie weryfikacji hasła

wrażliwość

Jeśli zostaną wykorzystane, te luki mogą umożliwić atakującym uzyskanie nieautoryzowanego dostępu do poufnych informacji lub ogólnie spowodować problemy

Kilka dni temu ukazała się informacja o luce, która została wykryta w przygotowanych przez firmę Red Hat łatkach dla bootloadera GRUB2. Już skatalogowane pod Luka CVE-2023-4001 umożliwia wielu systemom z UEFI ominięcie weryfikacji hasła ustaw na GRUB2, aby ograniczyć dostęp do menu startowego lub wiersza poleceń modułu ładującego.

Jeśli chodzi o podatność, wspomina się, że ta wynika ze zmiany dodanej przez firmę Red Hat do pakietu GRUB2 dołączony do RHEL i Fedory, więc problem nie pojawia się w głównym projekcie GRUB2 i dotyczy tylko dystrybucji, w których zastosowano dodatkowe poprawki dostarczone przez firmę Red Hat.

I Funkcja ochrony hasłem w GRUB-ieSłuży do zabezpieczenia wpisów menu startowego i powłoki wiersza poleceń menedżera rozruchu GRUB. Ten mechanizm, po włączeniu wraz z hasłem BIOS/UEFI, Chroni komputery przed nieautoryzowanymi użytkownikami które próbują uruchomić inny system operacyjny lub zwiększyć uprawnienia w zainstalowanym systemie operacyjnym.

Ustawianie hasła w GRUB-ie Osiąga się to za pomocą dwóch głównych poleceń: „hasło” i „hasło_pbkdf2”. Te polecenia tworzą użytkownika z określonym hasłem lub jego skrótem i tylko ci użytkownicy wymienieni w zmiennej środowiskowej „superusers” mogą edytować wpisy menu startowego i wykonywać polecenia w powłoce GRUB-a.

Problem leży w błędzie logicznym w jaki sposób moduł ładujący wykorzystuje identyfikator UUID do znalezienia urządzenia zawierającego plik konfiguracyjny chroniony hasłem, taki jak „/boot/efi/EFI/fedora/grub.cfg”. Błąd ten umożliwia użytkownikowi posiadającemu fizyczny dostęp do komputera podłączenie dysku zewnętrznego, takiego jak dysk flash USB, i skonfigurowanie go przy użyciu identyfikatora UUID odpowiadającego identyfikatorowi partycji startowej/rozruchowej zaatakowanego systemu.

W wielu systemach UEFI najpierw przetwarzane są dyski zewnętrzne i umieszczane są na liście wykrytych urządzeń przed jednostkami stacjonarnymi. Dlatego partycja /boot przygotowana przez atakującego będzie miała wyższy priorytet przetwarzania a GRUB2 spróbuje załadować plik konfiguracyjny z tej partycji.

Kiedy używasz polecenia „szukaj” w GRUB2 do zlokalizowania partycji, ustalane jest tylko pierwsze dopasowanie UUID, zatrzymując dalsze wyszukiwanie. Jeśli główny plik konfiguracyjny nie znajduje się na konkretnej partycji, GRUB2 wyświetli wiersz poleceń, dając użytkownikowi pełną kontrolę nad resztą procesu rozruchu.

Nieuprzywilejowani użytkownicy mogą poznać wartość UUID wolumenu „/boot”, umożliwiając im potencjalne wykorzystanie tej luki. Manipulując kolejnością urządzeń blokowych podczas rozruchu, na przykład podłączając dysk wymienny ze zduplikowanym UUID, użytkownicy mogą ominąć ochronę hasłem GRUB-a i uzyskać dostęp do powłoki bez uwierzytelniania.

Do określenia UUID można użyć narzędzia „lsblk”. partycji przez nieuprzywilejowanego użytkownika lokalnego, ale użytkownik zewnętrzny, który nie ma dostępu do systemu, ale może obserwować proces rozruchu, może w niektórych dystrybucjach określić UUID na podstawie diagnostyki i komunikatów wyświetlanych podczas rozruchu. Firma Red Hat zajęła się tą luką, dodając nowy argument do polecenia „search”, który umożliwia operacji skanowania UUID powiązanie tylko z urządzeniami blokującymi używanymi do uruchamiania menedżera rozruchu (tzn. partycja /boot powinna znajdować się tylko na tym samym dysku, co partycja systemowa EFI).

Alternatywnym (ale nie zaimplementowanym) podejściem byłoby użycie czegoś, co nie jest widoczne dla nieuprzywilejowanych użytkowników, jako podpisu w celu zlokalizowania woluminu „/boot”. Może to być plik o losowej nazwie, znajdujący się w katalogu z ograniczonymi uprawnieniami.

W końcu jeśli chcesz dowiedzieć się więcej na ten temat, możesz sprawdzić szczegóły w poniższy link.


Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: Miguel Ángel Gatón
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.