Jak zapewne wiecie pojawiła się informacja o skutecznym ataku na przeglądarkę Chrome (np. tu: Dziura i exploit na Google Chrome [0day] i u źródła: Google Chrome Pwned by VUPEN aka Sandbox/ASLR/DEP Bypass). Oczywiście całość okraszona podejściem "wiemy, ale nie powiemy", a konkretniej "wiemy, ale powiemy tylko naszym klientom, a producent niech sam dziury szuka". Z drugiej strony pojawiają się informacje, że dziura wcale nie jest w Chrome. I w tym momencie warto spróbować wykonać mały eksperyment myślowy: o co może chodzić.
O dziurze w Chrome(?)
To, czym wyróżnia się Chrome spośród innych przeglądarek to najlepszy w tej chwili sandbox. Większość kodu pracuje tylko z minimalnymi przywilejami, więc nawet jeśli jakaś podatność występuje, to jej skutki są ograniczone. Pilnuje to do pewnego stopnia sam system operacyjny Windows, bo piaskownica wykorzystana w Chrome opiera się głównie na mechanizmach dostępnych w tym systemie. Tu przy okazji warto przypomnieć, że sama piaskownica różni się między Windows XP i Windows Vista (i późniejszymi), bo części mechanizmów (patrz: integrity levels) w Windows XP po prostu nie ma.
Najciekawsze w całym tym zamieszaniu jest to jak (a może: czy) udało się uciec z sandboxa. Bo wcale tak być nie musiało.
Po uruchomieniu Chrome tworzonych jest w rzeczywistości kilka procesów (u mnie w tej chwili cztery):
- proces główny (broker),
- proces(y) dla poszczególnych kart (w uproszczeniu),
- proces dla rozszerzeń (extensions),
- proces dla pluginów,
Co ważne, tylko niektóre z tych procesów korzystają z sandboxa. Ciekawym celem ataku jest broker, który działa z pełnymi prawami użytkownika, który uruchomił przeglądarkę. Równie ciekawym celem jest proces, w którym uruchamiane są rozszerzenia (pluginy).
Jeśli chodzi o proces, w którym uruchamiane są pluginy, to sprawa wygląda na dość zagmatwaną. Istnieją istotne różnice między Windows XP i Windows Vista w ustawieniach zabezpieczeń tego procesu. W Windows XP domyślnie wygląda on na kompletnie niezabezpieczony. Po uruchomieniu Chrome z parametrem --safe-plugins aktywowany jest sandbox, ale jest on mniej "ścisły", niż ten na procesach obsługujących poszczególne karty. W przypadku Windows Vista (i podejrzewam, że na Windows 7 będzie podobnie/tak samo) ten sandbox dla pluginów jest (chyba) włączony domyślnie, podobnie jak w Windows XP jest on jednak mniej szczelny niż "standardowy" sandbox.
Na stronie VUPEN znajduje się informacja, że nie zostały wykorzystane żadne podatności w jądrze systemu Windows. Skoro tak, to raczej nie można oczekiwać, by proces z poziomu LOW był w stanie utworzyć proces na poziomie MEDIUM. Oczywiście, mógłby utworzyć nowy proces, ale nie wyżej niż na poziomie LOW właśnie (do integrity level dochodzi jeszcze token procesu, który też nie powinien mieć większych uprawnień, niż proces, który go utworzył). Według dostępnej demonstracji nowy proces był tworzony na poziomie MEDIUM, czyli tym, na którym operuje proces brokera oraz proces obsługujący pluginy.
Stawiałbym na dziurę w pluginie, ale nie można z całkowitą pewnością wykluczyć innych scenariuszy. Warto choćby mieć na uwadze to: Target bootstrapping. A ogólnie rzecz biorąc - ciekawy jestem jak to w rzeczywistości wygląda.
...a Firefox jak nie miał sandboxa, tak nadal go nie ma...
