r   e   k   l   a   m   a
r   e   k   l   a   m   a

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

Strona główna AktualnościOPROGRAMOWANIE

W grudniu Invisible Things Lab pokazało długo oczekiwaną wersję R2 Qubes OS-a – systemu operacyjnego budowanego od podstaw z myślą o bezpieczeństwie, bazującego na hiperwizorze Xen i uruchamiającego aplikacje i komponenty systemowe w izolowanych maszynach wirtualnych. Główną atrakcją wydania R2 było wprowadzenie obsługi programów dla Windows (system Microsoftu uruchamiany był w maszynie wirtualnej – szablonie, do którego bibliotek linkowały aplikacje). Okazuje się, że plany zespołu Rutkowskiej względem Windows były jednak daleko bardziej ambitne, nie kończyły się na wirtualizacji systemu w ramach Qubes OS-a. Niestety skończyło się na planach, 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ę w architekturze systemu. Dzięki frameworkowi Odyssey przestanie on być zależny od Xena. Korzystając z warstwy abstrakcji dla mechanizmu wirtualizacji, będzie można zastąpić Xena innymi hiperwizorami, na przykład ESXi, KVM czy Hyper-V. Oznaczałoby to, że jeśli ktoś nie chce korzystać z Linuksa jako systemu-hosta, mógłby sięgnąć po Windows. Deweloperzy Qubesa zaczęli się więc zastanawiać nad możliwością stworzenia środowiska, w którym domeny Xena byłyby zastąpione izolowanymi kontenerami w ramach zwykłego Windows, bez wykorzystania hiperwizora. Z takich właśnie rozważań zrodziła się idea Windows Native Isolation (WNI) dla systemu Qubes.

Rutkowska zgadza się oczywiście, że bezpieczeństwo takiego mechanizmu byłoby mniejsze, niż w „tradycyjnym” Qubesie, gdyż trudno porównywać zapewnianą izolację między procesami w monolitycznym jądrze z izolacją między maszynami wirtualnymi zapewnianymi przez hiperwizor. Pomyślcie o tych wszystkich systemowych wywołaniach Windows, wywołaniach GDI dostępnych dla każdego procesu, które zawierają pewnie tysiące błędów czekających tylko na odkrycie przez jakiegoś dzieciaka z interaktywnym desasemblerem. Pomyślcie o tych dziesiątkach tysięcy sterowników, które często ujawniają niezabezpieczone IOCTL, o parsowaniu przychodzących pakietów, informacji z urządzeń USB, metadanych systemu plików. Pomyślcie następnie o różnych dodatkowych usługach ujawnianych przez procesy systemowe, które choć nie są częścią jądra, to wciąż się im ufa, wciąż mają przywileje. A teraz pomyślcie o typowym interfejsie ujawnianym przez maszynę wirtualną: „po prostu” zwirtualizowane CPU, kilka emulowanych urządzeń (staromodny chipset z ery Pentium, adapter grafiki SVGA itp.) oraz zwirtualizowana pamięć – pisze szefowa Invisible Things Lab.

Mimo tych wszystkich problemów z Windows Native Isolation, rozwiązanie takie po pierwsze byłoby znacznie łatwiejsze do zaakceptowania przez użytkowników Windows (w końcu ilu z nich ma jakieś doświadczenie z wirtualizacją, szczególnie bezpośrednio na sprzęcie?), a po drugie i tak byłoby ono sporym krokiem naprzód względem obecnie dostępnych zabezpieczeń systemu Microsoftu, porównywanych przez Rutkowską do modelu bezpieczeństwa znanego jeszcze z systemu MS-DOS. Niestety bowiem, choć w Windows przybyło poszczególnych mechanizmów zabezpieczających, takich jak listy kontroli dostępu, które można zastosować do niemal każdego obiektu, to wciąż ulepszeń architektonicznych brak. Czemu więc nie spróbować wykorzystać tych całych zaawansowanych zabezpieczeń, by przynieść trochę prawdziwego bezpieczeństwa na desktopy z Windows? – pyta Rutkowska. Nie można pominąć też tego, że gdyby ludzie zaczęli korzystać z Qubes WNI, to z czasem mogliby chcieć przejść na „prawdziwego” Qubesa, nawet na bazie microsoftowego hiperwizora Hyper-V.

Prace nad Qubes WNI rozpoczęły się od dogłębnej analizy Windows pod kątem dostępnych mechanizmów, które pozwoliłyby na właściwe zabezpieczenie 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 tych prac i dokonane odkrycia przedstawione zostały w artykule pt. A crack on the glass autorstwa Rafała Wojdyły – i od razu trzeba przyznać: pomimo starań, w końcu Invisible Things Labs złożyło broń. Zarówno techniczne środki dostępne w Windows, jak i architektura tego systemu, zdaniem deweloperów Qubes OS-a nie dają możliwości wprowadzenia właściwej izolacji poszczególnych warstw. W szczególności problemy występują przy próbie zabezpieczenia zasobów GUI, a potencjalne rozwiązania tego problemu naruszają EULA Windows.

Dodatkowo, jak wyjaśnia Wojdyła, Windows nie jest w stanie właściwie wyizolować przestrzeni nazw obiektów między poszczególnymi domenami bezpieczeństwa, podsystem okienek uniemożliwia wykorzystanie więcej niż jednego desktopu jednocześnie, brakuje też systemowych mechanizmów dla ograniczania dostępu do API i wywołań systemowych. W teorii niektóre z takich ograniczeń mogłyby być wprowadzone bez konieczności łatania jądra NT, kwestia ta wymaga jednak dalszych badań.

Mimo że na razie z Qubes WNI nic nie będzie, polecamy zainteresowanym tą tematyką zapoznać się z artykułem Wojdyły, dającym bardzo dobry wgląd w stosunkowo mało znaną architekturę bezpieczeństwa systemów Microsoftu. Jak pisze Rutkowska, możliwe jest, że przedstawione wyniki są błędne, Invisible Things Lab po prostu pominęło coś w Windows istotnego, co umożliwiłoby zbudowanie Qubes WNI – więc prosi o uwagi wszystkich, którzy o czymś takim wiedzą.

r   e   k   l   a   m   a
© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.