Filozofia inżynierii: Joanna Rutkowska

Najważniejsze wnioski

• Zbudowała desktopowy system operacyjny przy założeniu, że zostanie skompromitowany. Joanna Rutkowska to polska badaczka bezpieczeństwa, która stworzyła Qubes OS — „rozsądnie bezpieczny system operacyjny” — wokół zasady bezpieczeństwa poprzez podział na przedziały. Zamiast próbować uwolnić system od błędów, Qubes dzieli cyfrowe życie użytkownika na odizolowane maszyny wirtualne zwane „qubes” (praca, prywatność, bankowość, treści niezaufane), tak aby naruszenie jednej z nich pozostało odgrodzone i nie sięgnęło pozostałych.¹²
• Reputację ofensywną zdobyła wcześniej — łamie systemy, by nauczyć się je izolować. Na Black Hat 2006 zaprezentowała Blue Pill, rootkit w postaci proof of concept, który wykorzystywał sprzętową wirtualizację AMD, aby wsunąć cienkiego, złośliwego hipernadzorcę pod działający system operacyjny, zamykając go wewnątrz maszyny wirtualnej, której ten nie był w stanie zobaczyć. Atakowanie najgłębszych warstw platformy nauczyło ją, którym warstwom nigdy nie wolno ufać.³
• Zasadę „nie ufaj infrastrukturze” przekuła w architekturę. W wykładzie zatytułowanym „Security Through Distrusting” Rutkowska dowodziła, że branżowy zwyczaj uznawania komponentów za „zaufane” jest naiwny i nie skaluje się — lepiej traktować każdy pojedynczy komponent jako potencjalnie skompromitowany, nie ufać niemal żadnemu z nich i nie mieć żadnego pojedynczego punktu awarii.⁵ Qubes to ten argument skompilowany do działającego desktopa.²
• Sondowała warstwy platformy, którym wszyscy inni ufali na ślepo. Poza Blue Pill prowadziła pionierskie prace nad atakami na System Management Mode oraz Intel Trusted Execution Technology, a w 2009 roku ukuła pojęcie ataku „Evil Maid”, łamiącego pełne szyfrowanie dysku, takie jak TrueCrypt, dzięki krótkiemu dostępowi fizycznemu. Każdy z tych ataków odwzorowywał granicę zaufania, która okazywała się kłamstwem.¹⁴

Zasada

„Całe oprogramowanie zawiera błędy… Zamiast próbować zapobiec każdemu możliwemu exploitowi, Qubes zakłada, że do wykorzystania luki dojdzie, i skupia się na ograniczeniu szkód.” — wprowadzenie do Qubes OS, parafrazujące jego założycielskie uzasadnienie²

Większość inżynierii bezpieczeństwa goni za celem nieosiągalnym. Audytuje się kod, łata dziury, utwardza konfigurację i wmawia sobie, że jeśli tylko zachowa się dość ostrożności, system będzie bezpieczny. Cała kariera Rutkowskiej to długi, cierpliwy dowód na to, że ów cel jest mirażem. Nowoczesny desktop uruchamia dziesiątki milionów linii kodu — jądro, sterowniki, przeglądarkę, czytnik PDF, oprogramowanie układowe — i każda z tych linii jest miejscem, w którym może się skryć błąd. Wszystkich pan nie znajdzie, a przeciwnikowi wystarczy jeden. Uczciwe pytanie nie brzmi więc „jak uwolnić to od błędów?”, lecz „kiedy — nie czy — coś się przedostanie, jak daleko zdoła sięgnąć?”²

Odpowiedź, którą zbudowała Rutkowska, to bezpieczeństwo poprzez izolację. Jeśli nie da się zapobiec włamaniu, można z góry zdecydować, jak daleko się ono rozejdzie. Qubes dzieli maszynę na osobne maszyny wirtualne — jedną do pracy, jedną do bankowości, jedną do prywatnego przeglądania, jedną do otwierania podejrzanych załączników — każdą działającą na hipernadzorcy Xen z własną granicą. Niech otworzy pan złośliwy odnośnik w niezaufanej qube, a szkodliwe oprogramowanie ląduje w szczelnie zamkniętym pokoju. Nigdy nie współdzieliło granicy zaufania z pańską qube bankową, więc nie sięgnie pańskich danych uwierzytelniających, a skompromitowaną qube można po prostu wyrzucić.¹² Świat fizyczny już tak działa: nie głosuje pan, nie śpi i nie przechowuje gotówki w jednym, niepodzielonym pokoju — a Qubes pyta, dlaczego pański komputer miałby to robić.²

Zasada ma drugą połowę, trudniejszą: nie ufaj infrastrukturze i zmniejsz to, czemu jesteś zmuszony ufać. W wykładzie „Security Through Distrusting” Rutkowska dowodziła, że nazwanie komponentu „zaufanym” nie jest komplementem — to przyznanie, że komponent ów jest „zdolny zniszczyć całą integralność mojego bezpieczeństwa”, jeśli zawiedzie.⁵ Dyscyplina polega więc na tym, by traktować niemal każdy komponent jako potencjalnie skompromitowany, usuwać pojedyncze punkty awarii i utrzymywać zaufaną bazę obliczeniową — kod, od którego poprawności zależy cała reszta — tak małą, jak to tylko możliwe.⁵² Ostatecznie czemuś zaufa pan i tak. Sztuka polega na tym, by owo coś było maleńkie, możliwe do skontrolowania i nieliczne.

Kontekst

Joanna Rutkowska urodziła się w 1981 roku w Warszawie i uzyskała tytuł magistra informatyki na Politechnice Warszawskiej.¹ Wyrosła nie jako obrończyni, lecz jako badaczka ofensywna — i to słynnie dobra — w połowie pierwszej dekady XXI wieku sondowała najniższe, najbardziej zaufane warstwy platformy x86, te, które bezpieczeństwo defensywne zwykle traktuje jak twardy grunt.

Jej przełomem był Blue Pill, zademonstrowany podczas Black Hat Briefings 3 sierpnia 2006 roku, obok prac pokazujących, jak pokonać mechanizmy ochrony jądra w Windows Vista. eWeek umieścił ją wśród „Pięciu hakerów, którzy odcisnęli piętno na 2006 roku”.¹³ W kwietniu 2007 roku założyła w Warszawie Invisible Things Lab — firmę doradczo-badawczą, która stała się domem dla jej prac nad bezpieczeństwem platform.¹ W kolejnych latach wraz ze współpracownikami — m.in. Alexandrem Tereshkinem i Rafałem Wojtczukiem — publikowała ataki na hipernadzorcę Xen, na Intel Trusted Execution Technology oraz na System Management Mode, głęboko uprzywilejowany tryb wykonywania „ring -2”, leżący poniżej nawet jądra systemu operacyjnego.¹ W 2009 roku ukuła pojęcie ataku Evil Maid, techniki opartej na dostępie fizycznym, która kompromituje proces rozruchu laptopa, by wykraść hasło do pełnego szyfrowania dysku, takiego jak TrueCrypt.⁴

Następnie zrobiła to, czego badacze ofensywni dokonują rzadko: zbudowała obronę. Prace nad Qubes OS rozpoczęły się około 2010 roku wraz z Wojtczukiem, a Qubes 1.0 ukazał się 3 września 2012 roku, oparty na zasadzie bezpieczeństwa poprzez podział na przedziały.¹ Kierowała projektem przez lata, a podejście to zyskało publiczne poparcie postaci tak różnych jak Edward Snowden i kryptograf Daniel J. Bernstein.² W późniejszych latach skierowała się ku pracom nad prywatnością i decentralizacją; szczegóły jej najnowszych projektów najlepiej czytać z jej własnych, aktualnych kanałów, a nie streszczać z drugiej ręki — niniejszy tekst trzyma się tego, co jest mocno udokumentowane.¹

Dzieło

Qubes OS: bezpieczeństwo poprzez podział na przedziały

Proszę zacząć tutaj, bo Qubes to zasada przekuta w coś, co naprawdę da się uruchomić. Projekt zaczyna od przyznania się do przegranej w wojnie, którą większość narzędzi bezpieczeństwa udaje, że wygrywa: całe oprogramowanie ma błędy, a niektóre z tych błędów da się wykorzystać.² Qubes nie próbuje być systemem nie do złamania. Próbuje być systemem, w którym złamanie nie ma większego znaczenia.

Mechanizmem jest hipernadzorca Xen. Pod wszystkim leży cienki hipernadzorca oraz specjalna domena administracyjna zwana dom0, która steruje wyświetlaniem i sprzętem, lecz celowo jest trzymana z dala od sieci. Powyżej działają qubes — lekkie maszyny wirtualne, każda przypisana do konkretnego celu i poziomu zaufania.¹² Może pan utrzymywać qube „pracową”, qube „bankową”, qube „prywatną” oraz qube „niezaufaną” do otwierania wszystkiego, co nadeszło od obcego. Okna każdej qube niosą niemożliwą do podrobienia, kolorową obwódkę, dzięki czemu od razu widać, do której domeny bezpieczeństwa należy dane okno.² Co kluczowe, qubes współdzielą główne systemy plików poprzez system szablonów, dzięki czemu pozostają lekkie i łatają się razem, podczas gdy ich dane prywatne pozostają odizolowane.² A do najbardziej ryzykownych zadań służą qubes jednorazowe — maszyny wirtualne, które uruchamiają się, by otworzyć jeden plik PDF lub jeden odnośnik, po czym samodestrukcyjnie znikają, zabierając ze sobą wszelką infekcję.²

Dlaczego ma to znaczenie jako inżynieria: Qubes przenosi jednostkę bezpieczeństwa z „maszyny” na „domenę”. Na zwykłym desktopie każda uruchamiana aplikacja współdzieli jedną przestrzeń adresową zaufania — pańską przeglądarkę, oprogramowanie do podatków i załącznik, którego nie powinien był pan otwierać, dzieli od siebie nawzajem jeden zły błąd. Qubes czyni z granicy między domenami ścianę egzekwowaną sprzętowo, a nie pełną nadziei konwencję. Koszt jest realny — więcej pamięci RAM, więcej tarcia, dyscyplina decydowania, do której qube należy dane zadanie — i Rutkowska szczerze przyznaje, że bezpieczeństwo poprzez nieufność „nie jest panaceum”, ponieważ wymienia się je za użyteczność.⁵ Lecz nagrodą jest to, że najgorszy przypadek przestaje być katastrofą. Włamanie to już nie „przejęli mój komputer”. To „przejęli jeden jednorazowy pokój, który właśnie zamierzam usunąć”.

Łamanie platformy: Blue Pill, SMM i Evil Maid

Nie da się zaprojektować dobrych granic izolacji, dopóki nie wie się dokładnie, które granice są fałszywe — a Rutkowska nauczyła się tego, atakując je. Blue Pill, jej demonstracja z Black Hat 2006, jest najjaśniejszym przykładem. Był to rootkit w postaci proof of concept, który wykorzystywał sprzętową wirtualizację AMD (AMD-V), aby dokonać czegoś zuchwałego: uruchomić cienkiego hipernadzorcę na działającej maszynie i w locie zmigrować działający system operacyjny do maszyny wirtualnej poniżej niego.³ Z wnętrza tej maszyny wirtualnej system operacyjny widziałby normalny świat — lecz hipernadzorca pod nim mógł przechwytywać „przerwania sprzętowe, żądania danych, a nawet czas systemowy”, podsuwając uwięzionemu systemowi dowolne odpowiedzi.³

Warto być precyzyjnym co do tego, czym Blue Pill był, a czym nie. Był proof of concept, a nie szkodliwym oprogramowaniem znalezionym na wolności, a jego najśmielsze twierdzenie — że taki rootkit-hipernadzorca dałoby się uczynić „w 100% niewykrywalnym” — było kwestionowane, a inni badacze proponowali wykrywanie oparte na pomiarze czasu.³ Lecz sporny nagłówek nie jest lekcją. Lekcją jest powierzchnia ataku, którą obnażył: wbudowane w każdy system operacyjny założenie, że warstwa, na której działa, jest nieszkodliwa. Blue Pill pokazał, że wirtualizacja może obrócić najbardziej uprzywilejowaną warstwę w bazę domową atakującego — i że cokolwiek uznaje pan za znajdujące się „poniżej” siebie, jest właśnie tym, czego nie da się zweryfikować „z góry”.

Ten sam instynkt napędzał resztę jej prac ofensywnych. Wraz ze współpracownikami atakowała System Management Mode, niejasny, hiperuprzywilejowany tryb oprogramowania układowego działający poniżej jądra, oraz Intel Trusted Execution Technology, funkcję, której całym celem było ustanowienie zaufania.¹ A w 2009 roku ukuła atak Evil Maid: niech pan zostawi zaszyfrowany laptop bez nadzoru w pokoju hotelowym, a „pokojówka” z krótkim dostępem fizycznym może zmajstrować przy niezaszyfrowanym bootloaderze tak, by przy następnym wpisywaniu przechwycił pańskie hasło.⁴ Pełne szyfrowanie dysku, takie jak TrueCrypt, było podatne, ponieważ kod rozruchowy nie potrafił uwierzytelnić się wobec użytkownika — nie miał pan sposobu, by stwierdzić, że program ładujący proszący o hasło wciąż jest pański.⁴ Każdy z tych ataków to mapa granicy zaufania, która nie utrzymała się. Architektka defensywna, która później zbudowała Qubes, już wiedziała, od środka, które ściany są nośne, a które jedynie namalowane.

Nie ufaj infrastrukturze: zmniejszanie zaufanej bazy obliczeniowej

Qubes to nie tylko „uruchom wszystko w maszynach wirtualnych”. Głębszą zasadą projektową jest minimalizowanie zaufanej bazy obliczeniowej i nieufność wobec niej — zbioru komponentów, na których poprawności opiera się bezpieczeństwo całego systemu. Wykład Rutkowskiej „Security Through Distrusting” formułuje tę filozofię bez ogródek: konwencjonalny pęd ku uznawaniu komponentów za „zaufane” jest „nazbyt naiwny i nieskalowalny”, ponieważ w bezpieczeństwie „zaufany” naprawdę oznacza komponent „zdolny zniszczyć całą integralność mojego bezpieczeństwa”, jeśli coś pójdzie nie tak.⁵ Właściwą reakcją jest założenie, że każdy pojedynczy komponent może być skompromitowany, nieufność wobec niemal wszystkich i takie projektowanie, by nie istniał żaden pojedynczy punkt awarii.⁵

Zasadę tę widać w konkretnych wyborach Qubes. Domena administracyjna dom0 jest celowo pozbawiona dostępu do sieci, ponieważ dom0 osiągalna przez sieć byłaby pojedynczym punktem, którego skompromitowanie oznacza przejęcie maszyny.² Obsługa sieci i USB są same wepchnięte do własnych, odizolowanych qubes, tak aby błąd w sterowniku karty sieciowej lub złośliwe urządzenie USB lądowały w piaskownicy, a nie w jądrze, któremu wszystko ufa.² Pliki przekraczające granice między domenami obsługiwane są defensywnie — ta sama logika „traktuj to jak potencjalnie przejęte”, którą Rutkowska stosowała do tego, jak Qubes przetwarza obrazy i pliki PDF.⁵ A qubes jednorazowe ucieleśniają nieufność najbardziej bezpośrednio: zamiast ufać, że czytnik PDF nie zostanie wykorzystany, zakłada pan, że zostanie, uruchamia go w maszynie wirtualnej, którą zaraz zniszczy, i pozwala eksplozji nastąpić w pustym pokoju.²

Wspólnym wątkiem jest pokora wobec własnego kodu. System, który ufa dużemu, złożonemu komponentowi, obstawia duży, złożony zakład. Architektura Rutkowskiej dąży do tego, by zakład był mały — by skurczyć zaufaną bazę obliczeniową do cienkiego hipernadzorcy i odciętej od sieci dom0, a niemal wszystko ponad tym traktować jako zbędne, wymienialne i z założenia wrogie.²⁵

Od desktopa ku decentralizacji

Rutkowska kierowała Qubes przez lata, a następnie zwróciła się ku szerszemu problemowi, który system operacyjny rozwiązuje jedynie częściowo: nawet doskonale podzielony na przedziały desktop wciąż ufa infrastrukturze wokół siebie — magazynowi w chmurze, sieci, usługom przechowującym pańskie dane.¹⁵ Jej późniejsze prace skierowały się ku prywatności i decentralizacji, rozszerzając tę samą nieufność na zewnątrz, od pojedynczej maszyny ku systemom, z którymi się ona komunikuje. Dokładny kształt i status tych projektów najlepiej zaczerpnąć z jej własnych, aktualnych tekstów, a nie parafrazować tutaj; tym, co przenosi się czysto, jest zasada, nie produkt. Instynkt pozostaje stały: założyć, że infrastruktura jest skompromitowana, i tak projektować, by owo założenie kosztowało jak najmniej.⁵

Metoda

Niech pan przeczyta wszerz Qubes, Blue Pill, ataki na SMM i TXT oraz „Security Through Distrusting”, a powracać będą te same zobowiązania. Metoda Rutkowskiej jest nie tyle hasłem, co zbiorem stałych nawyków.

Zakładaj kompromitację; projektuj pod zasięg rażenia. Ruchem założycielskim jest przyznanie, że zapobieganie zawiedzie, i zapytanie, jak daleko rozejdzie się włamanie.² W skali jest to — w dziedzinie bezpieczeństwa — odpowiednik tego, co Werner Vogels robi dla niezawodności — wszystko zawodzi przez cały czas, więc ograniczaj zasięg rażenia, zamiast udawać, że da się awarii uniknąć. Lekcja przenosi się daleko poza Qubes: nie projektuj pod przypadek, w którym nic się nie przedostanie; projektuj tak, by gdy już coś się przedostanie, było uwięzione w małej, jednorazowej celi. To bramka dowodów zastosowana do bezpieczeństwa — „nikt się jeszcze nie włamał” nie jest dowodem; „włamanie tutaj nie sięgnie tam” jest.

Nie ufaj infrastrukturze i dowiedź granicy. Traktuj każdy komponent jako potencjalnie przejęty i odmawiaj przyznawania zaufania domyślnie.⁵ To „Reflections on Trusting Trust” Thompsona przekute w architekturę desktopa: nie da się ufać temu, czego się nie zbadało, więc przestań ufać warstwom, których nie widzisz, i zamiast tego je odgrodź. Dyscyplina polega na pytaniu o każdy komponent: „jeśli to jest skompromitowane, co przejmuje?” — i na przerysowywaniu granic, aż odpowiedzią będzie „niemal nic”.

Złam to sam, zanim zrobi to ktoś inny. Obrona Rutkowskiej zbudowana jest na dekadzie ofensywy — Blue Pill, SMM, Evil Maid — bo nie da się odizolować granicy, której się najpierw nie udowodniło jako fałszywej.³⁴ To dokładnie ten instynkt, który Adi Shamir wniósł do kryptografii: atakuj, by bronić, i ufaj tylko temu, co przetrwa poważną próbę złamania. Stałym nawykiem jest najpierw założyć kapelusz atakującego, odwzorować, które z twoich założeń o zaufaniu są kłamstwami, i zbudować ściany tam, gdzie były kłamstwa.

Zmniejszaj zaufaną bazę obliczeniową. Im mniej linii kodu, od których zależy twoje bezpieczeństwo, tym mniejszy twój zakład.²⁵ Cienki hipernadzorca i odcięta od sieci dom0 to zakład możliwy do skontrolowania; monolityczne jądro z każdym sterownikiem i usługą wewnątrz granicy zaufania to zakład w ciemno. To minimalny godny produkt zastosowany do zaufania: najczystsza zaufana baza to ta najmniejsza, która wciąż wykonuje swoje jedyne zadanie. Zedrzyj zaufanie do tego, czemu ufać trzeba, a resztę uznaj za wrogą.

Bądź uczciwy co do kompromisu. Rutkowska nie sprzedaje na wyrost — mówi wprost, że bezpieczeństwo poprzez nieufność „nie jest panaceum” i kosztuje użyteczność oraz wygodę.⁵ Nawykiem jest nazwanie ceny bezpieczeństwa, które się kupuje, zamiast jej ukrywania, tak by następny inżynier mógł ją zważyć. Ta szczerość to jakość jest jedyną zmienną zastosowana do bezpieczeństwa: realna gwarancja, podana wraz z jej kosztami, jest warta więcej niż wygodna obietnica, która po cichu się nie utrzymuje. Granica, którą zrozumiałeś i wybrałeś, bije tę, którą założyłeś i odziedziczyłeś.

Łańcuch wpływów

Kto ją ukształtował

Społeczność badań ofensywnych połowy pierwszej dekady XXI wieku. Rutkowska wyrosła wewnątrz kultury ataków na platformy z Black Hat i niskopoziomowego hackingu systemów, gdzie praca polegała na znalezieniu założenia, którego nikt nie kwestionował, i złamaniu go.³ Centralny odruch tej kultury — nie ufaj warstwie, której ufają wszyscy — stał się kręgosłupem jej prac defensywnych. (Wpływ formujący)

Fala wirtualizacji sprzętowej. Blue Pill był możliwy tylko dlatego, że AMD-V i Intel VT-x właśnie uczyniły wirtualizację sprzętową powszechną.³ Ta sama technologia, której użyła jako broni w 2006 roku, stała się fundamentem, na którym zbudowała izolację w Qubes, gdzie Xen obraca hipernadzorcę z narzędzia atakującego w ścianę obrońcy.¹² (Wpływ bezpośredni)

Linia bezpieczeństwa Xena i hipernadzorców. Lata analizowania i atakowania Xena nauczyły ją dokładnie, jak silna — i jak krucha — jest izolacja hipernadzorcy, a wiedza ta ukształtowała decyzję Qubes o trzymaniu dom0 z dala od sieci i wepchnięciu sterowników do odizolowanych domen.¹² (Wpływ formujący)

Kogo ukształtowała

Świadome prywatności przetwarzanie danych. Qubes stał się rekomendowanym desktopem dla dziennikarzy, aktywistów i badaczy bezpieczeństwa, którzy muszą zakładać ukierunkowaną kompromitację — realnym narzędziem dla ludzi, których modelem zagrożenia jest państwo, a nie hasło.²

Sposób myślenia oparty na podziale na przedziały. „Bezpieczeństwo poprzez izolację” i „zmniejszaj zaufaną bazę obliczeniową” rozprzestrzeniły się daleko poza Qubes, na to, jak w całej branży rozumuje się o piaskownicach, izolacji kontenerów i wirtualizacji per aplikacja.²⁵

Obrońcy, którzy najpierw łamią. Rutkowska jest trwałym przykładem na to, że najsilniejszymi architektami defensywnymi często bywają byli atakujący — że odwzorowanie realnych granic zaufania poprzez ich łamanie jest warunkiem wstępnym ich poprawnego wytyczenia.³⁴

Wspólny wątek

Rutkowska jest zwornikiem izolacji w tej serii — postacią, która na „system zostanie naruszony” odpowiada nie rozpaczą, lecz architekturą. Adi Shamir atakuje, by bronić w kryptografii, ufając tylko temu, co przetrwa realną próbę złamania; Rutkowska wykonuje tę samą pętlę o jedną warstwę niżej, łamiąc hipernadzorców i łańcuchy rozruchowe, by zbudować desktop, który przetrwa ich kompromitację.³⁴ Thompson i Ritchie dali nam ostrzeżenie, że nie da się ufać temu, czego się samemu nie zbudowało i nie zbadało; „nie ufaj infrastrukturze” Rutkowskiej to owo ostrzeżenie przekute w działający system operacyjny, gdzie niezaufane warstwy są odgrodzone, a nie obstawiane nadzieją.⁵ A tam, gdzie Werner Vogels mówi wszystko zawodzi przez cały czas, więc ograniczaj zasięg rażenia w kwestii niezawodności, Rutkowska mówi to samo o bezpieczeństwie: Radia Perlman projektowała sieci, zakładając, że wrogi i zawodzący przypadek jest centrum projektu, a Rutkowska projektuje tak maszyny. Tam, gdzie Vogels ogranicza zawodzący dysk, a Perlman zawodzące łącze, Rutkowska mówi: atakujący jest już w środku — więc izoluj każdą domenę, nie ufaj żadnej warstwie i uczyń włamanie jednorazowym pokojem, który możesz wyrzucić. (Pomost serii)

Co z tego biorę

Lekcja, którą zachowuję od Rutkowskiej, to projektować pod włamanie, a nie przeciw niemu. Mój instynkt, jak u większości budujących, każe utwardzać rzecz — walidować dane wejściowe, łatać zależność, blokować konfigurację — i traktować bezpieczeństwo jako ścianę, którą staram się uczynić dość wysoką. „Całe oprogramowanie zawiera błędy” jest tu reprymendą: ściana zostanie naruszona, bo zawsze jest o jeden błąd więcej, a pytaniem, które naprawdę się liczy, jest to, co atakujący osiągnie, gdy już ją przeskoczy. Więc kiedy buduję teraz coś — granicę uwierzytelniania, usługę uruchamiającą niezaufane dane wejściowe, funkcję dotykającą pieniędzy — staram się pytać „gdy to zostanie skompromitowane, jaki jest zasięg rażenia?”, zanim zapytam „jak nie dopuścić tego do środka?”. Uczciwa wersja bezpieczeństwa to nie „nie widzę, jak to się łamie”. To „gdy się złamie, szkoda jest uwięziona w jednym pokoju, który mogę usunąć”.

Druga lekcja to rozsądna paranoja wobec tego, czemu jestem zmuszony ufać. Łatwo machnąć ręką, przepuszczając komponent jako „zaufany”, i pójść dalej, lecz Rutkowska przeformułowała dla mnie to słowo: nazwać coś zaufanym to przyznać, że może zniszczyć wszystko, jeśli zawiedzie. To zmieniło sposób, w jaki wytyczam granice. Każda biblioteka, którą wciągam, każda usługa, od której zależę, każda warstwa, na której działam, jest zakładem, że jest poprawna — a wielkość zakładu to wielkość mojej zaufanej bazy obliczeniowej. Staram się więc trzymać tę bazę małą i możliwą do skontrolowania, wpychać to, co ryzykowne i złożone, do piaskownic, które uznaję za wrogie, i być uczciwym, tak jak ona, że izolacja kosztuje mnie wygodę. Paranoja nie jest pesymizmem. Jest dyscypliną wiedzy o tym, czemu dokładnie ufam, i czynienia tej listy tak krótką, jak to tylko możliwe.

FAQ

Czym jest Qubes OS?

Qubes OS to darmowy, otwartoźródłowy, zorientowany na bezpieczeństwo desktopowy system operacyjny stworzony przez Joannę Rutkowską, opisywany przez projekt jako „rozsądnie bezpieczny system operacyjny”.² Wykorzystuje hipernadzorcę Xen, by podzielić przetwarzanie na odizolowane maszyny wirtualne zwane qubes — osobne przedziały dla aktywności takich jak praca, bankowość, prywatne przeglądanie i otwieranie niezaufanych plików. Ponieważ qubes są odizolowane, kompromitacja jednej z nich nie sięgnie pozostałych, więc szkoda z każdego pojedynczego włamania pozostaje odgrodzona. Obsługuje też qubes jednorazowe, które samodestrukcyjnie znikają po użyciu, i nadaje każdej domenie niemożliwą do podrobienia, kolorową obwódkę okna, dzięki czemu widać, do którego przedziału należy dane okno.¹²

Czym jest bezpieczeństwo poprzez izolację (podział na przedziały)?

Bezpieczeństwo poprzez izolację, czyli podział na przedziały, to zasada leżąca u sedna Qubes: zamiast próbować uwolnić oprogramowanie od błędów, zakłada się, że dojdzie do kompromitacji, i ogranicza szkodę poprzez podział systemu na odizolowane domeny.² Wprowadzenie do Qubes posługuje się analogią do życia fizycznego — w naturalny sposób rozdziela się aktywności do różnych pokoi — i stosuje ją do komputera, w którym wszystko współdzieliłoby inaczej jedną granicę zaufania.² Dopełniającą połową jest „nie ufaj infrastrukturze”: traktuj każdy komponent jako potencjalnie skompromitowany, usuwaj pojedyncze punkty awarii i utrzymuj zaufaną bazę obliczeniową tak małą, jak to możliwe.⁵

Czym był Blue Pill?

Blue Pill był rootkitem w postaci proof of concept, który Joanna Rutkowska zademonstrowała na Black Hat 3 sierpnia 2006 roku. Wykorzystywał sprzętową wirtualizację AMD (AMD-V), by uruchomić cienkiego, złośliwego hipernadzorcę na działającej maszynie i zmigrować działający system operacyjny do maszyny wirtualnej poniżej niego, tak aby hipernadzorca mógł przechwytywać i fałszować obraz sprzętu, przerwań, a nawet czasu systemowego widziany przez system operacyjny.³ Twierdzenie Rutkowskiej, że taki rootkit mógłby być „w 100% niewykrywalny”, było kwestionowane, a inni badacze proponowali wykrywanie oparte na pomiarze czasu. Była to badawcza demonstracja powierzchni ataku — założenia, że warstwa poniżej pańskiego systemu operacyjnego jest nieszkodliwa — a nie szkodliwe oprogramowanie znalezione na wolności.³

Czym jest atak Evil Maid?

Atak Evil Maid to technika oparta na dostępie fizycznym, którą Joanna Rutkowska nazwała we wpisie na blogu z 2009 roku. Jeśli atakujący uzyska krótki, nienadzorowany dostęp do pozostawionego bez opieki, zaszyfrowanego laptopa — powiedzmy w pokoju hotelowym — może zmajstrować przy niezaszyfrowanym kodzie rozruchowym tak, by potajemnie przechwycił hasło pełnego szyfrowania dysku użytkownika przy następnym jego wpisaniu.⁴ Systemy pełnego szyfrowania dysku, takie jak TrueCrypt, były podatne, ponieważ program ładujący nie potrafił uwierzytelnić się wobec użytkownika, więc ofiara nie miała sposobu, by odróżnić skompromitowany program ładujący od prawowitego.⁴ To wyrazista demonstracja tego, że samo szyfrowanie nie chroni maszyny, której przeciwnik może fizycznie dotknąć.

Źródła