TeamQuest Blog

RedHat i CentOS nie wstają

RedHat i CentOS nie wstają

Marcin Sarna , 03.08.2020 r.

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) xenialgrub2 (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.

Najnowsze oferty pracy:

Polecane wpisy na blogu IT:

Szukasz pracownika IT?

Dostarczymy Ci najlepszych specjalistów z branży IT. Wyślij zapytanie

Wyrażam zgodę TeamQuest Sp. z o.o. na przetwarzanie moich danych osobowych w celu marketingu produktów i usług własnych TeamQuest, w tym na kontaktowanie się ze mną w formie połączenia telefonicznego lub środkami elektronicznymi.
Administratorem podanych przez Ciebie danych osobowych jest TeamQuest Sp. z o.o., z siedzibą w Warszawie (00-814), ul. Miedziana 3a/21, zwana dalej „Administratorem".
Jeśli masz jakiekolwiek pytania odnośnie przetwarzania przez nas Twoich danych, skontaktuj się z naszym Inspektorem Ochrony Danych (IOD). Do Twojej dyspozycji jest pod adresem e-mail: office@teamquest.pl.
W jakim celu i na jakiej podstawie będziemy wykorzystywać Twoje dane? Dowiedz się więcej