Administratorzy systemów opartych o RedHata albo CentOS powinni się zastanowić czy na pewno chcą instalować łatkę na BootHole.

Patchujesz – nie bootujesz

Aktualizacje Enlarge/Security mające na celu załatanie luki BootHole UEFI powodują, że niektóre systemy Linux w ogóle nie mogą się uruchomić. Parafrazując znany internetowy mem: „nie możesz być podatny na działanie BootHole, jeśli nie możesz uruchomić systemu”.

Wczesnym rankiem 31 lipca 2020 roku w narzędziu do śledzenia błędów Bugzilla firmy Red Hat pojawił się błąd określony jako pilny. Jeden z użytkowników odkrył, że aktualizacja zabezpieczeń RHSA_2020:3216 (dot. grub2) i aktualizacja zabezpieczeń jądra RHSA-2020:3218 uniemożliwiały uruchomienie systemu RHEL 8.2. Błąd został zgłoszony jako powtarzalny w każdej czystej minimalnej instalacji Red Hat Enterprise Linux 8.2.

Secure Boot

Nowo odkryty bug eliminuje niejaki pierwotny bug, ale nie bez utworzenia kolejnego. Łatki miały na celu zamknięcie nowo odkrytej luki w menedżerze rozruchu GRUB2 o nazwie BootHole. Luka sama w sobie dawała hakerom możliwość zainstalowania złośliwego oprogramowania bootkit w systemie Linux, mimo że system ten jest chroniony przez UEFI Secure Boot. Niestety, łatka Red Hata do GRUB2 i jądra, po zastosowaniu, nie daje możliwości uruchomienia załatanych systemów. Potwierdzono, że problem dotyczy RHEL 7.8 i RHEL 8.2, a także może dotyczyć RHEL 8.1 i 7.9. Dotyczy to również dystrybucji pochodnej RHEL czyli CentOS.

Co robić

Aktualnie firma Red Hat odradza użytkownikom stosowanie poprawek zabezpieczeń GRUB2 (RHSA-2020:3216 lub RHSA-2020:3217) do czasu rozwiązania tych problemów. Jeśli więc administrujesz systemem RHEL lub CentOS i uważasz, że możesz mieć te poprawki zainstalowane na jakiejś maszynie, nie uruchamiaj ponownie systemu. Przeinstaluj pakiet, którego dotyczy problem, do niższej wersji, używając sudo yum downgrade shim \ * grub2 \ * mokutil i skonfiguruj yum, aby nie aktualizował tych pakietów, dodając tymczasowo exclude = grub2 * shim * mokutil do /etc/yum.conf.

Zobacz również: Btrfs wypiera ext4 na desktopach z Fedorą

Jeśli już zastosowałeś poprawki i bezowocnie próbowałeś ponownego uruchomienia, uruchom komputer z dysku DVD RHEL lub CentOS w trybie rozwiązywania problemów, skonfiguruj sieć, a następnie wykonaj te same czynności, które opisano powyżej, aby przywrócić funkcjonalność systemu.

Inne dystrybucje

Chociaż błąd został po raz pierwszy zgłoszony w Red Hat Enterprise Linux, najwyraźniej powiązane raporty o błędach napływają również z innych dystrybucji z różnych rodzin. Użytkownicy Ubuntu i Debiana zgłaszają systemy, które nie mogą się uruchomić po zainstalowaniu aktualizacji GRUB2, a firma Canonical wydała poradę zawierającą instrukcje dotyczące odzyskiwania systemów, których dotyczy problem.

Chociaż występowanie błędu po spatchowaniu GRUB2 powoduje podobne problemy, to ich zakres i wpływ na funkcjonowanie maszyny może być różny w zależności od dystrybucji. Jak dotąd wydaje się, że błąd GRUB2 w Debianie i Ubuntu dotyczy tylko systemów, które uruchamiają się w trybie BIOS (nie UEFI). W przypadku Ubuntu poprawka została już zatwierdzona w repozytorium, przetestowana i opublikowana w repozytorium aktualizacji. Zaktualizowane i wydane pakiety, grub2 (2.02~beta2-36ubuntu3.27) xenial i grub2 (2.04-1ubuntu26.2) focal, powinny więc rozwiązać problem w przypadku użytkowników Ubuntu.

Natomiast dla użytkowników Debiana poprawka jest dostępna w nowo zatwierdzonym pakiecie grub2 (2.02 + dfsg1-20 + deb10u2).

W tej chwili nie wiadomo czy inne dystrybucje, np. Arch czy Gentoo, także cierpią na wspomniane problemy.

Przypomnijmy, że TeamQuest pisał już niedawno o innej dziurze związanej z UEFI i Ubuntu.