9 obserwujących
32 notki
41k odsłon
  1181   1

Nie instaluj misiu podejrzanych programów (do tego o x86 i Secure Boot)

Na samym początku platforma x86 nie miała żadnych zabezpieczeń, jeżeli chodzi o ochronę kodu przed zmianą przez inny kod. Procesory były wtedy bardzo proste i obsługiwały wyłącznie tzw. tryb rzeczywisty (real mode), co oznaczało, że każdy proces miał dostęp do całej przestrzeni adresowej i wszystkich zasobów sprzętowych.

Potem zdecydowano, że konieczna jest ochrona. Wprowadzono tryb chroniony (protected mode). Pierwsze sprzętowe implementacje były proste, i stąd np. w procesorze 80286 można było go włączyć, ale już powrót do trybu rzeczywistego (bodajże) we wszystkich wypadkach wymagał restartu systemu. W wielkim uproszczeniu dostaliśmy wtedy dwa poziomy uprawnień, i pojawiło się coś takiego jak tryb jądra (kod uruchomiony w tym trybie może zarządzać innymi procesami) i tryb użytkownika (procesy mogą działać tylko w obrębie otrzymanych uprawnień), jak również obsługa pamięci wirtualnej (część dysku może działać jak RAM).

Platforma się rozbudowywała. Oprócz trybu 16-bitowego pojawił się również tryb 32-bitowy, w którym można było obsłużyć aż do 4GB RAM. Ilość tranzystorów rosła, a stopień skomplikowania spowodował, że nawet Intel na początku miał z tym problemy (część pierwszych procesorów 80386 działała poprawnie tylko z kodem 16-bitowym). Doszła obsługa wieloprocesorowości, producenci dodawali też coraz więcej rdzeni w obrębie jednego układu scalonego (konieczne było rozwiązanie np. różnych problemów współbieżności).

Co jednak ważne przez lata, BIOS praktycznie wszędzie nie miał żadnej ochrony. Pojawiały się kolejne wirusy, które potrafiły go zmieniać albo kasować, a producenci nie implementowali nawet prostego microswitcha, który to blokował. Podobnie mieliśmy do czynienia z różnymi cyfrowymi mikrobami, które modyfikowały zawartość sektorów rozruchowych dysków czy dyskietek. Kilka firm stworzyło wtedy inicjatywę Secure Computing, w ramach której zaczęto przygotowywać mechanizmy, które miały m.in. temu przeciwdziałać. Powstały takie rozwiązania jak TPM (Trusted Platform Module) czy Secure Boot (kontrola tego, czy oprogramowanie startowe nie uległo zmianie). O pierwszym z nich zaczęło być głośno w kontekście Windows 11 (system w większości przypadków, jeśli nie zawsze, ma wymagać modułu TPM 2.0), a drugie jest o tyle ciekawe, że domyślnie to Microsoft decyduje, które oprogramowanie (tzn. z jakim podpisem cyfrowym) można wystartować.

Zatrzymajmy się w tym momencie. Współczesna platforma x86 to sprzęt, w którym dostępne jest co najmniej kilka rdzeni procesora (w następstwie błędów, o ile nich nie załatamy, wątki i procesy mogą podkradać dane innym), mamy też różne kanały szybkiej transmisji (teoretycznie bezpieczne, a czasami podatne na włamania – wystarczy wspomnieć problemy z Thunderbolt czy USB), interfejsy do debugowania, (zbyt) rozbudowane UEFI, opcje wirtualizacji czy (w przypadku systemów z Intelem) Intel ME, czyli nadrzędny procesor , który może robić co chce z „właściwą” częścią (i masy właściwie nie wiedzą co tam siedzi).

W tym tygodniu zostałem przywołany do tablicy i skarcony, że nie powinienem proponować instalowania oprogramowania z nieznanych źródeł. Zasada ogólnie dobra, ale… jak zawsze diabeł tkwi w szczegółach. Pomińmy w tym momencie oczywistą oczywistość, że nikt nie powinien się ślepo słuchać jakiegoś kolesia z Internetu.

Sprawa dotyczyła Ubuntu odpalonego na laptopie produkowanym przez Clevo. Pisałem o oprogramowaniu dostarczanym przez firmę Tuxedo Computers. Mają oni repozytoria z kodem źródłowym na GitHub i proponują również skompilowane wersje binarne. Ich domena tuxedocomputers.com jest ważna od 2008. Załóżmy teraz, że nie kupili jej od nikogo na targu, i używają jej od nowości.

Jak widać, mamy firmę, która sprzedaje laptopy, dodaje do nich własne oprogramowanie i jest na rynku od 13 czy 14 lat (zależy jak liczyć). Oprogramowanie powstało na podstawie oryginalnych aplikacji Clevo, które udostępniono pod Windows (zrobiono tzw. reverse engineering). Służy m.in. do kontroli prędkości wentylatorów. Teoretycznie powinienem oczywiście skorzystać do tego zadania z domyślnego interfejsu oferowanego pod Linuxem przez lm-sensors czy fancontrol, ale tego nie ma dla Clevo. Mógłbym zmienić odpowiednie opcje w BIOS/UEFI, ale tych nie ma w przypadku mojego laptopa.

Tak więc podsumowując – mamy firmę działającą od kilkunastu lat. Nie dostarczyła (jeszcze?) standardowego interfejsu, i w sumie biję się w piersi, że np. nie zacząłem od analizy każdej linijki ich kodu źródłowego. Jeżeli przejść na ten poziom bezpieczeństwa, to powinienem też sprawdzić i skompilować od zera każdy pakiet dostarczany przez Ubuntu (przypomnijmy sobie aferę, w której jeden z uniwersytetów podobno w celach badawczych celowo umieszczał błędny kod w jądrze Linuxa). Wskazane byłoby pewnie też usunięcie UEFI i wgranie do laptopa „wolnej” jego implementacji (powinna pasować od Lemura Pro, i potrzebowałbym tylko programatora). Wtedy miałbym jednakże jeszcze problem z Intel ME, mikrokodem procesora czy firmware dysku (nie wiadomo, co tam siedzi, prawda?)

Lubię to! Skomentuj1 Napisz notkę Zgłoś nadużycie

Więcej na ten temat

Komentarze

Inne tematy w dziale Technologie