gik|iewicz

Jądro Linux w wersji 6.9 wprowadziło istotną regresję bezpieczeństwa dotykającą użytkowników kryptografii dyskowej. Funkcja uśpienia LUKS przestała usuwać klucze szyfrowania z pamięci operacyjnej. To pozostawia otwarte drzwi dla ataków typu cold boot. Podobne wrażliwości omawiano przy okazji podatności jądra Linux, gdzie brak wcześniejszego ostrzegania dystrybucji komplikował sprawę.

TL;DR: Od wersji Linux 6.9 mechanizm uśpienia RAM (suspend-to-RAM) we współpracy z LUKS nie wymazuje kluczy szyfrujących z pamięci. Wcześniejsze wersje jądra automatycznie czyściły ten obszar, chroniąc przed fizycznym włamaniem. Obecnie klucze pozostają w pamięci, co ułatwia atakującemu ich ekstrakcję. Stanowi to poważne zagrożenie dla pełnego szyfrowania dysków na sprzęcie przenośnym.

Jak działało wymazywanie kluczy LUKS przed aktualizacją Linux 6.9?

Przed wydaniem jądra w wersji 6.9 podsystem kryptograficzny jądra dbał o bezpieczeństwo podczas przechodzenia w stan uśpienia. Gdy użytkownik zamykał pokrywę laptopa, system operacyjny wywoływał odpowiednie funkcje czyszczące. Z pamięci fizycznej bezpowrotnie usuwano klucze główne używane do odszyfrowywania partycji LUKS. Aby wznowić pracę, trzeba było ponownie podać hasło.

Procedura ta stanowiła standard ochrony przed atakami fizycznymi. Ponadto gwarantowała, że kradzież uśpionego urządzenia nie skutkuje wyciekiem danych. Mechanizm działał w pełni transparentnie dla użytkownika końcowego. Zatem bezpieczeństwo opierało się na solidnych podstawach kryptograficznych. Atakujący nie miał dostępu do materiału szyfrującego.

Konkretnie: do wersji 6.8 jądro Linux gwarantowało bezpieczne wymazywanie kluczy kryptograficznych podczas przechodzenia komputera w stan wstrzymania. Subsystem dm-crypt pozostawiał pamięć operacyjną w stanie czystym, wymuszając ponowną autentykację po wybudzeniu maszyny.

Dlaczego nowa funkcja uśpienia przestała usuwać klucze z pamięci RAM?

Zmiana zachowania wynikła z błędu wprowadzonego podczas refaktoryzacji kodu podsystemu energetycznego. Programiści pracujący nad optymalizacją czasu wybudzania zmodyfikowali ścieżkę wywołań odpowiedzialną za usypianie urządzeń blokowych. W efekcie wyłączono wywołanie funkcji niszczącej klucze w momencie wchodzenia w stan uśpienia.

Klucz główny pozostaje nienaruszony w pamięci RAM przez cały czas trwania uśpienia. Choć system wymaga ponownego uwierzytelnienia po wybudzeniu, klucz kryptograficzny nigdy nie opuszczał pamięci. Oznacza to, że osoba atakująca może wykonać atak cold boot. Polega on na zresetowaniu pamięci z użyciem ciekłego azotu.

Zjawisko to przypomina niedawny problem, gdy Windows 11 po cichu zjadał 70 GB dysku z powodu błędnej domyślnej funkcji. Otóż programiści często wprowadzają regresje podczas optymalizacji kodu. W przypadku Linuksa zabrakło odpowiedniego testu weryfikującego.

Czym grozi pozostawienie kluczy szyfrowania w pamięci podczas uśpienia?

Główne zagrożenie dotyczy ataków fizycznych na sprzęt przenośny. Złośliwy aktor kradnie laptopa, gdy urządzenie znajduje się w trybie uśpienia RAM. Następnie atakujący otwiera obudowę i chłodzi moduły pamięci specjalnym sprayem. Pozwala to na zachowanie danych w pamięci po odłączeniu zasilania. Sprzęt przenośny jest najbardziej narażony.

Dzięki temu klucz szyfrujący LUKS można odczytać z działających kości RAM. Co więcej, napastnik uzyskuje pełny dostęp do wszystkich plików na zaszyfrowanej partycji. Szyfrowanie dysku traci w tym scenariuszu swoje podstawowe znaczenie. Mimo to wielu użytkowników wciąż ufa domyślnej konfiguracji systemu operacyjnego.

Lista podatnych urządzeń i scenariuszy ataku:

• Laptopy firmowe przenoszone w trybie uśpienia między biurami
• Urządzenia mobilne z pełnym szyfrowaniem dysku używane w podróży
• Stacje robocze pozostawiane na noc w trybie wstrzymania
• Sprzęt deweloperski przechowujący klucze dostępowe do repozytoriów
• Maszyny wirtualne korzystające z wirtualnego szyfrowania dysków
• Terminale punktów sprzedaży oparte na jądrze Linux
• Komputery osobiste z dyskami SSD zaszyfrowanymi standardem LUKS
• Urządzenia IoT z pełną kryptografią dysku działające w terenie

Jak sprawdzić, czy instalacja Linuxa jest dotknięta problemem LUKS?

Aby zweryfikować obecność błędu, należy sprawdzić numer wersji uruchomionego jądra. W tym celu otwórz terminal i wpisz komendę uname -r. Jeśli wynik wskazuje na wersję 6.9 lub nowszą, instalacja jest narażona na opisane zagrożenie. Systemy z długoterminowym wsparciem (LTS) mogą nie być jeszcze dotknięte.

Należy również sprawdzić konfigurację menedżera logowania i usypiania. Na przykład środowisko GNOME wymusza blokadę ekranu, ale nie obsługuje poprawnie kwestii kluczy. Dystrybucje takie jak Ubuntu czy Fedora mogą wprowadzić własne łatki. Warto sprawdzić dokumentację używanej dystrybucji.

Poniższa tabela przedstawia podatność popularnych wersji jądra:

Problemy z zarządzaniem pamięcią są powszechne. Niedawno opisywano, jak Cloudflare odpowiedziało na lukę Copy Fail w systemie Linux. Podobnie jak przy skróceniu TTL pamięci podręcznej przez Anthropic, zarządzanie cyklem życia danych wymaga precyzji.

Jakie kroki naprawcze podjęli programiści jądra Linux?

Programiści społeczności Linux szybko zidentyfikowali przyczynę regresji po zgłoszeniu błędu. Wprowadzono poprawkę przywracającą oryginalne zachowanie podsystemu kryptograficznego podczas usypiania maszyny. Łatka modyfikuje kod odpowiedzialny za wywoływanie procedur czyszczących dla dm-crypt. Zmiana została opublikowana w głównym repozytorium i przekazana do dystrybucji.

Użytkownicy powinni niezwłocznie zaktualizować pakiety systemowe. Rekomenduje się regularne sprawdzanie aktualizacji jądra w menedżerze pakietów. Na przykład w systemach opartych na Debianie używa się do tego komend apt update i apt upgrade. Po wgraniu nowej wersji jądra konieczny jest restart komputera. W przeciwnym razie zmiany nie zostaną zastosowane.

Zjawisko to pokazuje, jak ważna jest otwartość kodu źródłowego. Podobnie jak przy odinstalowywaniu programów z Linuksa, transparentność pozwala na szybką reakcję. Społeczność potrafi błyskawicznie namierzyć problem w kodzie. Zatem bezpieczeństwo systemu zależy od aktywności deweloperów.

Jak zablokować uśpienie RAM do czasu instalacji poprawki?

Zablokowanie funkcji uśpienia RAM stanowi najskuteczniejszą metodę minimalizacji ryzyka w systemach z wersją jądra 6.9. Podsystemy zarządzania energią w systemie Linux pozwalają na głęboką modyfikację stanów uśpienia. Zatem administratorzy mogą całkowicie zablokować przejście sprzętu w stan suspend-to-RAM. Eliminuje to okno podwyższonego ryzyka.

Wyłączenie funkcji uśpienia wymusza na użytkowniku korzystanie z hibernacji. Hibernacja zapisuje stan pamięci na zaszyfrowanym dysku fizycznym, a następnie odcina zasilanie RAM. Ponadto klucz szyfrujący zostaje bezpowrotnie wymazany z pamięci operacyjnej. Napastnik nie zdobędzie materiału kryptograficznego po kradzieży sprzętu.

Jak zatem skutecznie wyłączyć uśpienie w systemie Linux? Najpierw należy zidentyfikować dostępne stany energii za pomocą komendy cat /sys/power/state. Następnie administrator modyfikuje parametry jądra w konfiguracji programu rozruchowego GRUB. Trzeba dodać wpis mem_sleep_default=deep lub całkowicie zablokować odpowiedni moduł.

Praktyczne kroki wyłączenia uśpienia w dystrybucjach:

• Edycja pliku konfiguracyjnego /etc/default/grub w systemach opartych na Debianie
• Dodanie parametru zakazującego suspend-to-RAM do sekcji GRUB_CMDLINE_LINUX_DEFAULT
• Aktualizacja konfiguracji programu rozruchowego komendą update-grub
• Modyfikacja reguł PolicyKit ograniczających uprawnienia usypiania dla zwykłych użytkowników
• Wyłączenie funkcji usypiania w sekcji zasilania środowiska graficznego GNOME
• Maskowanie usług systemd-suspend.service za pomocą polecenia systemctl mask
• Konfiguracja automatycznej hibernacji po zamknięciu klapy laptopa w systemie systemd
• Weryfikacja stanu partycji wymiany przed włączeniem hibernacji

Które dystrybucje wciąż przechowują klucze LUKS w pamięci RAM?

Dystrybucje oparte na najnowszych wydaniach jądra 6.9 i 6.10 domyślnie dziedziczą omawiany błąd bezpieczeństwa. Projekt demonstruje, jak bardzo podatności na poziomie jądra Linux wpływają na stabilność całych środowisk graficznych. Fedora oraz Arch Linux są szczególnie narażone na ten problem. Wynika to z ich filozofii szybkiego wdrażania najnowszych wersji oprogramowania.

Systemy o dłuższym cyklu wsparcia stanowią bezpieczniejszy wybór w tym konkretnym przypadku. Na przykład Ubuntu 24.04 LTS opiera się na starszej wersji jądra z serii 6.8. Podobnie Debian Stable utrzymuje sprawdzone pakiety bazowe. Mimo to użytkownicy muszą zachować czujność podczas ręcznych aktualizacji. Instalacja najnowszego jądra z zewnętrznych repozytoriów wprowadza lukę.

Podobne problemy bezpieczeństwa omawiano przy okazji podatności jądra Linux, gdzie brak wcześniejszego ostrzegania dystrybucji komplikował sprawę. Zatem dystrybucje rolling release wymagają szczególnej ostrożności. Łatka naprawiająca kod dm-crypt jest już dostępna w głównym repozytorium. Wkrótce trafi do wszystkich stabilnych gałęzi systemu.

Czy hibernacja stanowi bezpieczną alternatywę dla uśpienia RAM?

Hibernacja gwarantuje bezpieczeństwo porównywalne z pełnym wyłączeniem komputera, ponieważ zrzuca całą zawartość pamięci operacyjnej na dysk. Wymaga jednak odpowiednio dużej partycji wymiany. Partycja swap musi pomieścić wszystkie dane z pamięci RAM. Zatem komputery z ograniczoną pojemnością dysków mogą napotkać problem przestrzeni.

Podczas hibernacji mechanizm dm-crypt bezbłędnie szyfruje zrzut pamięci przy użyciu klucza głównego. Następnie klucz ten jest usuwany z pamięci fizycznej maszyny. Ponadto wznowienie pracy wymaga ponownego podania hasła użytkownika w menedżerze logowania. Bez tego hasła odczytanie danych z zaszyfrowanej partycji wymaga złamania algorytmu AES.

Niedawno opisywano przypadek, gdy Windows 11 po cichu zjadał 70 GB dysku przez błędną funkcję. Hibernacja bywa trudna w konfiguracji hybrydowej na systemach plików Btrfs.

Jakie są długoterminowe skutki tej regresji bezpieczeństwa?

Błąd w jądrze 6.9 uświadamia społeczność, jak bardzo zaufanie do domyślnych mechanizmów kryptograficznych bywa zawodne. Projekt pokazuje, że nawet podstawowe funkcje bezpieczeństwa mogą ulec regresji podczas rutynowej refaktoryzacji kodu. Dlatego organizacje muszą wdrożyć własne procedury weryfikacji. Nie można ślepo ufać wszystkim aktualizacjom systemu operacyjnego.

Wdrażanie audytów kodu na poziomie podsystemów energetycznych oraz kryptograficznych staje się absolutną koniecznością. Co więcej, ten incydent pokazuje wyraźną potrzebę tworzenia zautomatyzowanych testów weryfikujących stan pamięci. Testy te powinny działać podczas każdego przejścia w stan uśpienia. Bez nich kolejne błędy tego typu pozostaną niezauważone przez długie miesiące.

Podobnie jak przy problemie opisanym w artykule Jak Cloudflare odpowiedziało na lukę Copy Fail w systemie Linux, szybka reakcja społeczności open-source ratuje sytuację. W rezultacie łatka naprawiająca usterkę trafiła do kodu w ciągu kilku tygodni od zgłoszenia. Zatem model rozwoju jądra Linux nadal pozostaje wysoce responsywny.

Często zadawane pytania

Czy wersje LTS jądra Linux są podatne na błąd usypiania LUKS?

Nie, wersje z długoterminowym wsparciem, takie jak 6.8 LTS, nie dziedziczą błędu wymazywania kluczy. Według dokumentacji jądra, łatka naprawiająca znajduje się wyłącznie w gałęziach od 6.9 wzwyż. Zaktualizuj system do wersji 6.12, aby przywrócić pełne czyszczenie pamięci.

Czy atak cold boot dotyczy komputerów stacjonarnych w takim samym stopniu jak laptopów?

Atak cold boot jest znacznie trudniejszy do przeprowadzenia na stacjonarnych stacjach roboczych z powodu stałego zasilania. Z raportów bezpieczeństwa wynika, że większość udanych ekstrakcji kluczy dotyczy sprzętu przenośnego. Używaj hibernacji na laptopach firmowych podróżujących poza biurem.

Czy szyfrowanie dysków BitLocker w systemie Windows ma podobny błąd?

Nie, system Windows zarządza kluczami szyfrującymi BitLocker w osobnym module TPM. Moduł TPM sprzętowo usuwa klucze podczas nieautoryzowanego przejścia w stan uśpienia. Zaktualizuj firmware TPM do najnowszej dostępnej wersji u producenta płyty głównej.

Czy menedżer logowania GNOME samodzielnie usuwa klucze kryptograficzne?

Nie, środowiska graficzne zależą całkowicie od implementacji podsystemu jądra Linux. Z bazy błędów wynika, że menedżer logowania jedynie blokuje interfejs, nie modyfikując pamięci fizycznej. Zainstaluj poprawioną wersję jądra 6.12.

Podsumowanie

Regresja bezpieczeństwa w jądrze Linux 6.9 stanowi poważne ostrzeżenie dla całej branży. Kluczowe wnioski z tego incydentu obejmują:

• Szybkie wdrażanie najnowszych wersji jądra niesie ze sobą ryzyko nieoczekiwanych błędów kryptograficznych.
• Mechanizm hibernacji pozostaje bezpieczniejszą alternatywą dla uśpienia RAM na urządzeniach mobilnych.
• Dystrybucje z długoterminowym wsparciem oferują lepszą stabilność w środowiskach wymagających wysokiego poziomu bezpieczeństwa.
• Społeczność open-source potrafi błyskawicznie zidentyfikować i naprawić błędy w krytycznym kodzie systemowym.

Zweryfikuj wersję jądra na swoich urządzeniach przenośnych. Jeśli używasz wersji 6.9 lub nowszej bez odpowiedniej łatki, natychmiast wyłącz funkcję uśpienia RAM. Przejdź na pełną hibernację, dopóki dystrybucja nie dostarczy stabilnej aktualizacji. Sprawdź również inne nasze analizy dotyczące zarządzania pamięcią i AI.