Paweł Goleń, blog

Integrity levels

Mechanizm protected mode wykorzystuje integrity levels (patrz: Windows Vista Integrity Mechanism Technical Reference ), czego ubocznym skutkiem jest fakt, iż to dodatkowe zabezpieczenie dostępne jest od Windows Vista w górę.

Zadaniem integrity levels jest ochrona systemu przed modyfikacją. Koncepcja jest prosta - w tym samym kontekście (w sensie - jako ten sam użytkownik) uruchomione może być wiele procesów. Procesy te można jednak obdarzyć różnym "poziomem zaufania". Te procesy, które mają do czynienia z niezaufanymi danymi i są wystawione na atak tego zaufania dostają mniej. Takie procesy mogą zostać uruchomione z mniejszym integrity level, w związku z czym będą objęte dodatkowymi ograniczeniami. Jakimi? Tu warto zapoznać się z Inside Windows Vista User Account Control. Poniżej wersja skrócona, która powinna wystarczyć do zrozumienia tematu:

Istnieją następujące integrity levels:

• Low Mandatory Level
• Medium Mandatory Level
• High Mandatory Level
• System Mandatory Level

Jednocześnie istnieją trzy polityki:

• no-write-up,
• no-read-up,
• no-execute-up,

Dla plików domyślna polityka to no-write-up co oznacza, że proces o niższym integrity level nie może modyfikować zawartości plików, może natomiast ją czytać.

Eksperyment, czyli jak to wygląda w praktyce

Przy okazji mały eksperyment...

>dir *.txt /b
test1.txt
test2.txt

>chml test1.txt -q

The file test1.txt has no integrity label.
Windows treats unlabeled objects like this:

File test1.txt's integrity level: medium
Inheritance flags:
  No inheritance flags
Integrity policies:
  No read up: disabled
  No execute up: disabled
  No write up: enabled


>chml test2.txt -q

File test2.txt's integrity level: High
Inheritance flags:
  No inheritance flags
Integrity policies:
  No read up: disabled
  No execute up: disabled
  No write up: enabled

Jak widać są dwa pliki, które mają dwa różne integrity level. W przypadku pliku test1.txt jest to Medium (wartość domyślna), w przypadku test2.txt w sposób jawny został ustawiony poziom High. Pomijając integrity levels "klasyczne" ACL dla obu plików wygląda tak samo.

Zgodnie z polityką no-write-up możliwe jest odczytanie zawartości obu plików (proces cmd.exe pracuje na poziomie Medium):

>type test1.txt
test1

>type test2.txt
test2

Próba zapisu do pliku test2.txt kończy się jednak niepowodzeniem:

>echo test3 >> test1.txt

>echo test3 >> test2.txt
Access is denied.

Oczywiście możemy plik test2.txt dodatkowo oznakować w taki sposób, by obowiązywały zasady no-write-up oraz no-read-up (można wykorzystać do tego narzędzie chml). Po tych zmianach ustawienia dla pliku test2.txt wyglądają w sposób następujący:

File test2.txt's integrity level: High
Inheritance flags:
  No inheritance flags
Integrity policies:
  No read up: enabled
  No execute up: disabled
  No write up: enabled

Niepowodzeniem zakończy się nie tylko próba zapisania, ale również próba odczytania zawartości pliku:

>echo test4 >> test2.txt
Access is denied.

>type test2.txt
Access is denied.

A teraz mała niespodzianka:

>del test2.txt

>dir *.txt /b
test1.txt

Jak widać zasada no-write-up nie oznacza, że tak chronionego pliku nie można usunąć. A przynajmniej nie w każdym przypadku.

Eksperyment II: proces ograniczony

Rezultatów powyższego eksperymentu nie można wprost przekładać na ograniczenia istniejące w trybie protected mode w Internet Explorer. Tym razem podobne działania zostaną przeprowadzone z procesu o integrity level na poziomie Low (np.: psexec -l -i cmd.exe).

>chml test1.txt -q

The file test1.txt has no integrity label.
Windows treats unlabeled objects like this:

File test1.txt's integrity level: medium
Inheritance flags:
  No inheritance flags
Integrity policies:
  No read up: disabled
  No execute up: disabled
  No write up: enabled


>type test1.txt
test1

>echo test2 >> test1.txt
Access is denied.

>del test1.txt
Access is denied.

W tym wypadku możliwe jest odczytywanie zawartości pliku, nie ma natomiast możliwości jego modyfikacji lub usunięcia.

Co oferuje protected mode?

W ten nieco przydługi sposób chciałem pokazać, że protected mode ma uniemożliwić (a przynajmniej - utrudnić) np. zainstalowanie malware w systemie z wykorzystaniem podatności w przeglądarce. Mechanizm protected mode natomiast nie chroni przed odczytaniem plików.

Jak jest w Chrome

Nieco inaczej zrealizowany jest sandbox w przypadku przeglądarki Chrome. Dobry opis wykorzystanego mechanizmu znajduje się w dokumentacji projektu w dokumencie o zaskakującej nazwie Sandbox, przy czym warto zapoznać się również z On Chromium and Practical Windows Sandboxing, co zresztą powtarzam już nie pierwszy raz.

Różnica, na którą chcę zwrócić uwagę znajduje się w sekcji The token. Chrome korzysta z istniejącego w systemie mechanizmu restricted token. Jakie są tego skutki? Zgodnie z dokumentacją:

(...) The system uses the list of restricting SIDs when it checks the token's access to a securable object. When a restricted process or thread tries to access a securable object, the system performs two access checks: one using the token's enabled SIDs, and another using the list of restricting SIDs. Access is granted only if both access checks allow the requested access rights. (...)

Skutki tego prostego dość zabiegu są znaczne i dobrze oddaje je zdanie zawarte w dokumentacji Chrome:

(...) With the caveats described above, it is near impossible to find an existing resource that the OS will grant access with such a token. (...)

Podkreślam, że w tym wypadku chodzi o dowolny typ dostępu (odczyt, zapis, usunięcie, ...). Przy okazji ciekawy jest też pomysł opisany w sekcji Target bootstrapping.

Kolejnym tematem, któremu trzeba poświęcić chwilę uwagi jest to, jak Chrome wyświetla strony. Jest to również opisane w dokumentacji w How Chromium Displays Web Pages, przy czym warto też przeczytać Multi-process Architecture. Tu warto zauważyć, że większość potencjalnie niebezpiecznych operacji wykonywanych jest przez render process, który domyślnie uruchamiany jest w sandbox. Jeśli w kodzie pracującym w tym procesie istnieje podatność, skutki jej wykorzystania są niewielkie, bo kolejną linią obrony są mechanizmy zaimplementowane w systemie operacyjnym. Istnieje również inna potencjalna droga ataku - atak na "główny" proces przeglądarki. Przykład? Proszę bardzo: Security: sandbox bypass due to directory traversal opening Web Database files.

Warto zapoznać się z Chromium Security Bugs, kilka z podatności tam wymienionych daje możliwość uruchomienia kodu. Kod ten będzie jednak (zwykle) będzie pracował w piaskownicy, z której będzie dopiero trzeba uciec.

W czym Chrome jest lepsze, a w czym gorsze?

Istotną przewagą Chrome z sandboxem nad Internet Explorer z protected mode są większe ograniczenia narzucane na kod pracujący w piaskownicy. Słabością Chrome jest natomiast fakt, że pluginy (np. mający ostatnimi czasy bogatą historię Flash Player) uruchamiane są domyślnie poza sandboxem. W przypadku Internet Explorer pluginy są objęte restrykcjami wynikającymi z protected mode.

Ciekawy jestem jak będzie wyglądał sandbox w Firefox, jeśli w końcu się pojawi...