Matthew Garrett, znany deweloper jądra Linux, który otrzymał nagrodę od Fundacji Otwartych Projektów za wkład w rozwój oprogramowania open source, opisał istotę mechanizmu SBAT (Secure Boot Advanced Targeting), stworzonego w celu blokowania luk w zabezpieczeniach w bootloaderze bez potrzeby unieważniania podpisu cyfrowego, a także jego rolę w niedawnym incydencie związanym z aktualizacją systemu Windows, która spowodowała problem z uruchamianiem niektórych dystrybucji Linuxa zainstalowanych obok Windows na systemach z włączonym UEFI Secure Boot. W skrócie, winne są zarówno firma Microsoft, która nie przeprowadziła pełnych testów aktualizacji i zastosowała ją w systemach, w których nie powinna była, jak i deweloperzy niektórych dystrybucji Linuxa, którzy nie zaktualizowali bootloadera GRUB oraz numeru generacji SBAT, gdy w GRUB wykryto luki w zabezpieczeniach.
Poniżej znajduje się tłumaczenie notatki Garretta:
Podczas opracowywania specyfikacji UEFI Secure Boot wszyscy uczestnicy byli, delikatnie mówiąc, nieco naivni. Główna koncepcja bezpieczeństwa Secure Boot polega na tym, że cały kod, który jest uruchamiany w uprzywilejowanym środowisku na poziomie jądra, musi być sprawdzany przed wykonaniem — firmware sprawdza bootloader, bootloader sprawdza jądro, a jądro sprawdza jakikolwiek dodatkowy kod, który zostanie załadowany w trakcie wykonania, i teraz mamy zaufane środowisko do egzekwowania dowolnej innej polityki bezpieczeństwa, którą chcemy. Oczywiście ludzie mogą popełniać błędy, ale w specyfikacji przewidziano sposób unieważniania podpisanych komponentów, które okazały się niewiarygodne: wystarczy dodać skrót niesprawdzonego kodu do zmiennej, a następnie odmówić ładowania czegokolwiek z tym skrótem, nawet jeśli jest to podpisane zaufanym kluczem.
Niestety, jak się okazało, problem leży w skali. Każda dystrybucja Linuxa działająca w ekosystemie Secure Boot generuje własne pliki binarne bootloadera, a każdy z nich ma swój własny hash. Gdy w źródłowym kodzie takiego bootloadera zostanie wykryta luka, konieczne jest wycofanie dużej liczby różnych plików binarnych. A pamięć potrzebna do przechowywania zmiennej zawierającej wszystkie te hashe jest ograniczona. Po prostu zabraknie miejsca, aby dodawać nowe zestawy hashy za każdym razem, gdy okaże się, że GRUB (bootloader, pierwotnie napisany w czasach, gdy nie praktykowano ochrony rozruchu, i mający kilka osobnych parserów obrazów img, a także parser czcionek) ma jeszcze jeden mechanizm, który może być wykorzystany przez atakującego do uruchomienia dowolnego kodu, dlatego potrzebne było inne rozwiązanie.
Tym rozwiązaniem jest SBAT. Ogólna koncepcja SBAT jest dość prosta. Każdy ważny komponent w łańcuchu rozruchowym ogłasza pokolenie bezpieczeństwa, które jest zawarte w podpisanym pliku binarnym. Gdy luka zostaje wykryta i naprawiona, to pokolenie rośnie. Następnie można wydać aktualizację określającą minimalne pokolenie — komponenty rozruchowe będą porównywać następny element w łańcuchu, sprawdzając jego nazwę i numer pokolenia w stosunku do tych, które są przechowywane w zmiennej firmware'u, i decydować, czy go wykonać, czy nie. Zamiast wycofywać dużą liczbę oddzielnych hashy, można wydać jedną aktualizację, która po prostu mówi: „Każda wersja GRUB z poziomem bezpieczeństwa poniżej tego numeru jest uważana za niewiarygodną.”
Dlaczego to stało się nagle aktualne? SBAT został opracowany wspólnie przez społeczność Linuxa oraz Microsoft, a Microsoft postanowił wydać aktualizację dla Windows, która instruowałaby systemy, aby nie ufały wersjom GRUB z poziomem bezpieczeństwa poniżej określonego poziomu. Zostało to zrobione, ponieważ te wersje GRUB miały rzeczywiste luki w zakresie bezpieczeństwa, które umożliwiały cyberprzestępcom naruszenie łańcucha bezpiecznego rozruchu Windows, a my widzieliśmy rzeczywiste przykłady złośliwego oprogramowania, które chciało to zrobić (Black Lotus wykorzystał lukę w bootloaderze Windows, ale luka w GRUB była równie skuteczna). Patrząc na to czysto z perspektywy bezpieczeństwa, to jak najbardziej uzasadnione pragnienie.
Jeśli chodzi o komunikat „Coś poszło nie tak” i niemożność uruchomienia z powodu tej aktualizacji. Jest on generowany przez shim, a nie przez jakiś kod od Microsoftu. Shim uwzględnia aktualizacje SBAT, i aby nie podważać zasad bezpieczeństwa przyjętych przez inne bootloader'y w systemie, a chociaż Microsoft wydał aktualizację SBAT, to właśnie bootloader Linux odmawia uruchomienia starszych wersji GRUB. Wszystko działa tak, jak powinno.
Problem, z którym zmaga się wiele osób, polega na tym, że kilka dystrybucji Linux nie wydało wersji GRUB z nowszym pokoleniem bezpieczeństwa, dlatego te wersje GRUB uważane są za niebezpieczne (warto zauważyć, że GRUB jest podpisywany przez same dystrybucje, a nie przez Microsoft, więc nie ma żadnego zewnętrznego opóźnienia). Z zamiarem Microsoftu, aktualizacja Windows Update miała stosować aktualizację SBAT tylko do systemów działających tylko na Windows, a wszelkie instalacje z podwójnym rozruchem pozostałyby narażone na ataki, dopóki zainstalowana dystrybucja nie zaktualizowałaby GRUB i nie poprawiłaby pokolenia SBAT. Niestety, jak to teraz jest oczywiste, nie zadziałało to tak, jak planowano, i co najmniej niektóre systemy z podwójnym rozruchem zastosowały aktualizację, a shim tej dystrybucji odmówił załadowania GRUB tej dystrybucji.
Jakie są tego konsekwencje? Microsoft (z zrozumiałych powodów) nie chciał, aby Windows mógł być atakowany za pomocą podatnej wersji GRUB, którą można by oszukać, aby wykonać dowolny kod, a następnie wprowadzić bootkita do jądra Windows podczas uruchamiania. Microsoft osiągnął to, wydając aktualizację Windows, która zaktualizowała zmienną SBAT, wskazując, że podatne wersje GRUB nie powinny być uruchamiane na tych systemach. Dostarczony przez dystrybucję shim bootloader pierwszego etapu odczytywał tę zmienną, odczytywał sekcję SBAT z zainstalowanej kopii GRUB, rozumiał, że są w konflikcie i odmawiał załadowania grub z komunikatem „Coś poszło nie tak”. Ta aktualizacja nie powinna była być stosowana do systemów z podwójnym rozruchem, ale mimo to została zastosowana.
Podsumowując:
1) Microsoft zastosował aktualizację do systemów, do których nie powinna była być stosowana
2) Niektóre dystrybucje Linux nie zaktualizowały bootloadera GRUB i pokolenia bezpieczeństwa SBAT, gdy w GRUB odkryto podatności.
W rezultacie niektórzy ludzie nie mogą załadować swoich systemów. Uważam, że jest tu wielu winnych. Microsoft powinien przeprowadzić więcej testów, aby upewnić się, że instalacje z podwójnym bootowaniem mogą być właściwie rozpoznawane. Ale dystrybucje, które dostarczają podpisane bootloader'y, powinny upewnić się, że je aktualizują i poprawiają generację zabezpieczeń, ponieważ w przeciwnym razie dostarczają wektor ataku, który może być wykorzystany do włamań do innych systemów operacyjnych, co stanowi pewnego rodzaju naruszenie umowy społecznej wokół tego wszystkiego.
Niestety, ofiarami tutaj są głównie końcowi użytkownicy, którzy stają przed problemem, że system nagle odmawia załadowania tego systemu operacyjnego, który chcą uruchomić. To nigdy nie powinno się zdarzyć. Nie sądzę, by ankieta wśród użytkowników końcowych dotycząca tego, czy chcą aktualizacji systemu z bezpiecznym bootowaniem, przyniosła dobry rezultat, i chociaż w pewnym sensie skłaniam się ku temu, że bezpieczne bootowanie UEFI nie przynosi korzyści większości użytkowników końcowych, to jednak jest to coś, czego nie chcemy odkryć po takich incydentach. Dlatego sympatyzuję z tym, że jest to włączone domyślnie, popieram jego domyślne włączenie i rozumiem wybór Microsoft, z wyjątkiem niefortunnej próby uniknięcia aktualizacji na systemach z podwójnym bootowaniem.
W każdym razie, byłem mocno zaangażowany w wdrażanie tego mechanizmu dla Linuxa w 2012 roku i napisałem pierwszy prototyp Shim (który jest teraz znacznie lepszym bootloaderem, wspieranym przez szerszą grupę ludzi, i którego nie dotykałem od kilku lat), więc jeśli chcesz obwinić kogoś konkretnego, nie krępuj się obwiniać mnie. To nie powinno się zdarzyć, a jeśli nie jesteś Microsoftem ani dystrybucją Linuxa, to nie jest twoja wina. Przepraszam.
Źródło: opennet.ru
