Joanna Rutkowska: nie sposób zapewnić bezpieczeństwa przez izolację w Windows

W grudniu Invisible Things Lab pokazało długo oczekiwanąwersję R2 Qubes OS-a – systemu operacyjnego budowanego odpodstaw z myślą o bezpieczeństwie, bazującego na hiperwizorze Xen iuruchamiającego aplikacje i komponenty systemowe w izolowanychmaszynach wirtualnych. Główną atrakcją wydania R2 było wprowadzenieobsługi programów dla Windows (system Microsoftu uruchamiany był wmaszynie wirtualnej – szablonie, do którego bibliotek linkowałyaplikacje). Okazuje się, że plany zespołu Rutkowskiej względemWindows były jednak daleko bardziej ambitne, nie kończyły się nawirtualizacji systemu w ramach Qubes OS-a. Niestety skończyło się naplanach, ale w trakcie prac dowiedziano się o bezpieczeństwie„okienek” wiele wcześniej nieznanych rzeczy.Kolejna wersja Qubes OS-a przynieść ma poważną zmianę warchitekturze systemu. Dzięki frameworkowi Odyssey przestanie on byćzależny od Xena. Korzystając z warstwy abstrakcji dla mechanizmuwirtualizacji, będzie można zastąpić Xena innymi hiperwizorami, naprzykład ESXi, KVM czy Hyper-V. Oznaczałoby to, że jeśli ktoś niechce korzystać z Linuksa jako systemu-hosta, mógłby sięgnąć poWindows. Deweloperzy Qubesa zaczęli się więc zastanawiać nadmożliwością stworzenia środowiska, w którym domeny Xena byłybyzastąpione izolowanymi kontenerami w ramach zwykłego Windows, bezwykorzystania hiperwizora. Z takich właśnie rozważań zrodziła sięidea Windows Native Isolation (WNI) dla systemu Qubes.[img=izolacja]Rutkowska zgadza się oczywiście, że bezpieczeństwo takiegomechanizmu byłoby mniejsze, niż w „tradycyjnym” Qubesie,gdyż trudno porównywać zapewnianą izolację między procesami wmonolitycznym jądrze z izolacją między maszynami wirtualnymizapewnianymi przez hiperwizor. Pomyślcie o tych wszystkichsystemowych wywołaniach Windows, wywołaniach GDI dostępnych dlakażdego procesu, które zawierają pewnie tysiące błędów czekającychtylko na odkrycie przez jakiegoś dzieciaka z interaktywnymdesasemblerem. Pomyślcie o tych dziesiątkach tysięcy sterowników,które często ujawniają niezabezpieczone IOCTL, o parsowaniuprzychodzących pakietów, informacji z urządzeń USB, metadanychsystemu plików. Pomyślcie następnie o różnych dodatkowych usługachujawnianych przez procesy systemowe, które choć nie są częścią jądra,to wciąż się im ufa, wciąż mają przywileje. A teraz pomyślcie otypowym interfejsie ujawnianym przez maszynę wirtualną: „poprostu” zwirtualizowane CPU, kilka emulowanych urządzeń(staromodny chipset z ery Pentium, adapter grafiki SVGA itp.) orazzwirtualizowana pamięć –pisze szefowa Invisible Things Lab.Mimo tych wszystkich problemów z Windows Native Isolation,rozwiązanie takie po pierwsze byłoby znacznie łatwiejsze dozaakceptowania przez użytkowników Windows (w końcu ilu z nich majakieś doświadczenie z wirtualizacją, szczególnie bezpośrednio nasprzęcie?), a po drugie i tak byłoby ono sporym krokiem naprzódwzględem obecnie dostępnych zabezpieczeń systemu Microsoftu,porównywanych przez Rutkowską do modelu bezpieczeństwa znanegojeszcze z systemu MS-DOS. Niestety bowiem, choć w Windows przybyłoposzczególnych mechanizmów zabezpieczających, takich jak listykontroli dostępu, które można zastosować do niemal każdego obiektu,to wciąż ulepszeń architektonicznych brak. Czemu więc niespróbować wykorzystać tych całych zaawansowanych zabezpieczeń, byprzynieść trochę prawdziwego bezpieczeństwa na desktopy z Windows?– pyta Rutkowska. Nie można pominąć też tego, że gdyby ludziezaczęli korzystać z Qubes WNI, to z czasem mogliby chcieć przejść na„prawdziwego” Qubesa, nawet na bazie microsoftowegohiperwizora Hyper-V. Prace nad Qubes WNI rozpoczęły się od dogłębnej analizy Windowspod kątem dostępnych mechanizmów, które pozwoliłyby na właściwezabezpieczenie systemu – wyizolowanie interfejsu użytkownika,sieci, jądra i pozostałych komponentów. Towarzyszyły temu teżprzeróbki samego frameworka Odyssey, aby jako „hiperwizor”mógł przyjąć osobliwą konstrukcję, którą miał być WNI. Przebieg tychprac i dokonane odkrycia przedstawione zostały w artykulept. A crack on the glass autorstwa Rafała Wojdyły – i odrazu trzeba przyznać: pomimo starań, w końcu Invisible Things Labszłożyło broń. Zarówno techniczne środki dostępne w Windows, jak iarchitektura tego systemu, zdaniem deweloperów Qubes OS-a nie dająmożliwości wprowadzenia właściwej izolacji poszczególnych warstw. Wszczególności problemy występują przy próbie zabezpieczenia zasobówGUI, a potencjalne rozwiązania tego problemu naruszają EULA Windows.Dodatkowo, jak wyjaśnia Wojdyła, Windows nie jest w staniewłaściwie wyizolować przestrzeni nazw obiektów między poszczególnymidomenami bezpieczeństwa, podsystem okienek uniemożliwia wykorzystaniewięcej niż jednego desktopu jednocześnie, brakuje też systemowychmechanizmów dla ograniczania dostępu do API i wywołań systemowych. Wteorii niektóre z takich ograniczeń mogłyby być wprowadzone bezkonieczności łatania jądra NT, kwestia ta wymaga jednak dalszychbadań.Mimo że na razie z Qubes WNI nic nie będzie, polecamyzainteresowanym tą tematyką zapoznać się z artykułem Wojdyły, dającymbardzo dobry wgląd w stosunkowo mało znaną architekturębezpieczeństwa systemów Microsoftu. Jak pisze Rutkowska, możliwejest, że przedstawione wyniki są błędne, Invisible Things Lab poprostu pominęło coś w Windows istotnego, co umożliwiłoby zbudowanieQubes WNI – więc prosi o uwagi wszystkich, którzy o czymś takimwiedzą.