Podatność nosząca nazwę BootHole pozwala atakującym wpłynąć bezpośrednio na proces rozruchowy systemu, który poprzedza start samego systemu operacyjnego.
Proces bootowania stanowi element kluczowy dla zabezpieczenia urządzenia. Opiera się on na różnych komponentach określanych jako bootloaders lub programy rozruchowe. Odpowiadają one za ładowanie firmware dla wszystkich komponentów hardware’owych urządzenia. Wróćmy do BootHole. Jest to podatność w GRUB2 – czyli jednym z najpolularniejszych komponentów typu bootloaders obecnie na rynku. Jest on wykorzystywany we wszystkich największych dystrybucjach Linux, w części maszyn działających pod kontrolą Windows OS, macOS a także systemach opartych na BSD. Wychodzi więc na to, że Secure Boot nie jest taki bezpieczny…
Główne zadanie Secure Boot to ochrona procesów przed złośliwymi aplikacjami. Podczas procesu rozruchu, wszystko co ładuje się wcześniej ma większe uprawnienia niż to, co ładuje się później. Atakujący, mogą wykorzystać podatność BootHole do ingerencji w proces rozruchowy urządzenia, a co za tym idzie kontrolować sposób ładowania składników systemu operacyjnego, omijając zabezpieczenia. Podatność można wykorzystać także w systemach, które wykorzystują Secure Boot nawet jeśli nie korzystają one z GRUB2. Czyli chodzi o wszystkie urządzenia Win z Secure Boot podpisanych standardowym certyfikatem Microsoft Third Party UEFI. Problem więc dotyczy większości laptopów, komputerów stacjonarnych, serwerów i stacji roboczych, a także urządzeń i sprzętu sieciowego używanego w przemyśle, opiece zdrowotnej i finansach.
BootHole – źródło problemu
BootHole to podatność przeciążenia bufora, która wynika ze sposobu w jaki GRUB2 parsuje zawartość pliku konfiguracji GRUB2. Plik konfiguracyjny GRUB2 jest plikiem tekstowym i zwykle nie jest podpisany tak jak inne pliki czy .exe. Atakujący może zmienić zawartość pliku konfiguracyjnego GRUB2 i w ten sposób umożliwić ładowanie złośliwego oprogramowania przed startem systemu operacyjnego.
Udana eksploatacja tej podatności umożliwiłaby wyłączenie weryfikacji integralności kodu, dzięki czemu staje się możliwe ładowanie większej liczby sterowników lub plików .exe. W ten sposób atakujący jest w stanie przejąć pełną kontrolę nad systemem operacyjnym, aplikacjami oraz danymi zgromadzonymi na urządzeniu. Atak jest możliwy nawet wtedy gdy Secure Boot jest włączony i poprawnie weryfikuje sygnatury wszystkich załadowanych plików wykonywalnych.
Niełatwe rozwiązanie problemu…
… w które zaangażowanych jest wiele podmiotów – od wydawców systemów operacyjnych, poprzez vendorów, na administratorach kończąc. Wszystkie wersje GRUB2, które ładują polecenia z zewnętrznego pliku konfiguracyjnego grub.cfg, są podatne na atak. Rozwiązanie problemu wymaga wydania nowych instalatorów oraz programów rozruchowych dla wszystkich wersji Linux. Także vendorzy muszą wypuścić nowe wersje swoich podkładek bootloadera z podpisem Microsoft 3rd Party UEFI CA. Nowe programy rozruchowe będą musiały zostać podpisane i wdrożone – a ich wcześniejsze wersje, podatne na atak, wycofane, by uniemożliwić ich użycie w przyszłości. Administratorzy będą musieli przeprowadzić pełny update wszystkich systemów operacyjnych – także zainstalowanych obrazów, w tym kopii systemów, które w przypadku awarii można uruchomić w zwirtualizowanej postaci. Jak widać, nie jest to łatwe zadanie i z całą pewnością będzie wymagało przeprowadzenia wielu testów nim wszystkie zmiany zostaną finalnie wprowadzone. Wdrożenie wszystkich wymaganych środków naprawczych będzie niestety długotrwałym procesem.
