piaskownica

Piaskownica (sandbox) to ograniczone, kontrolowane środowisko wykonawcze, które nie pozwala potencjalnie złośliwemu oprogramowaniu sięgać po zasoby systemu inne niż te, do których zostało uprawnione ^[1]. NIST przytacza też szerszą definicję: system, w którym niezaufana aplikacja działa w ściśle kontrolowanym środowisku, z uprawnieniami ograniczonymi do niezbędnego minimum, zwykle bez dostępu do systemu plików i sieci ^[2]. Piaskownica występuje w dwóch rolach. Chroni zaufany program przed skutkami jego przejęcia, jak w przeglądarce, albo służy do celowego uruchamiania podejrzanych plików i obserwowania ich zachowania.

Jak działa

Piaskownica nie próbuje odgadnąć, czy kod jest złośliwy. Zakłada najgorsze i ogranicza to, co kod może zrobić, niezależnie od danych wejściowych. Dokumentacja Chromium formułuje cel wprost: piaskownica ma dawać twarde gwarancje, co dany fragment kodu może, a czego nie może zrobić, bez względu na jego wejście ^[3]. Opiera się przy tym na zabezpieczeniach systemu operacyjnego, tak by kod nie mógł wprowadzać trwałych zmian w komputerze ani czytać poufnych informacji ^[3].

W architekturze Chromium działają dwa rodzaje procesów ^[3]. Uprzywilejowany proces zarządzający, zwany brokerem, określa politykę, uruchamia procesy docelowe i wykonuje w ich imieniu dozwolone operacje ^[3]. W procesach docelowych działa cały kod objęty ograniczeniami; w Chromium są to procesy renderujące strony ^[3]. Wśród zasad projektowych dokumentacja wymienia zasadę najmniejszych uprawnień i założenie, że kod w piaskownicy jest złośliwy ^[3].

Przebieg żądania z procesu w piaskownicy pokazuje schemat poniżej.

RYS. 1Proces w piaskownicy prosi brokera o operację

Odmiany

Mechanizmy izolacji różnią się poziomem, na którym działają, i celem.

Środowisko analizy wymaga osobnego omówienia. CERT Polska wyjaśnia, że analiza dynamiczna polega na uruchomieniu programu, obserwacji jego zachowania i analizie skutków ^[4]. Środowisko do takiej analizy ma przypominać typowy komputer użytkownika, dawać powtarzalne wyniki i być odizolowane, by uruchomienie złośliwego kodu nie zagrażało innym urządzeniom w sieci ^[4]. Najczęściej używa się do tego maszyn wirtualnych z przygotowaną migawką systemu ^[4]. Pokrewne pojęcia to kwarantanna podejrzanych plików i air gap, czyli fizyczne odcięcie od sieci.

W WordPressie

WordPress korzysta z piaskownicy przeglądarki przy osadzaniu treści. Funkcja wp_filter_oembed_result() filtruje kod HTML osadzeń oEmbed; jeśli adres nie należy do listy zaufanych dostawców, kod jest mocno filtrowany ze względów bezpieczeństwa ^[7]. Do ramek osadzeń od niezaufanych dostawców funkcja dopisuje przy tym atrybut sandbox="allow-scripts" ^[7]. Osadzona treść może więc wykonywać skrypty, ale bez innych uprawnień, które atrybut domyślnie odbiera.

MDN opisuje atrybut sandbox jako zestaw ograniczeń nakładanych na treść ramki; pusta wartość włącza wszystkie ograniczenia, a kolejne słowa kluczowe znoszą wybrane ^[6]. MDN przestrzega przed łączeniem allow-scripts z allow-same-origin, gdy osadzony dokument pochodzi z tej samej domeny, bo wtedy może on sam usunąć atrybut sandbox i ochrona znika ^[6]. Ta uwaga dotyczy motywów i wtyczek, które wstawiają własne ramki na stronę example.com.

<!-- Ramka z treścią zewnętrzną: skrypty tak, dostęp do domeny strony nie. -->
<iframe src="https://widget.example.com/" sandbox="allow-scripts"></iframe>

Drugi przykład to WordPress Playground. Dokumentacja opisuje go jako WordPress działający w całości po stronie klienta w WebAssembly, bez uwierzytelniania i serwera, odizolowany w przeglądarce i bez trwałych skutków poza piaskownicą ^[8]. Nadaje się to do sprawdzenia nieznanej wtyczki albo motywu, zanim trafią na środowisko testowe czy produkcję. Nie jest to jednak analiza bezpieczeństwa: Playground nie wykryje tylnej furtki, która uaktywnia się dopiero na prawdziwym serwerze.

Kod PHP na zwykłym hostingu nie działa w piaskownicy. Kod wtyczki działa w tym samym procesie PHP co rdzeń WordPressa, więc podatność we wtyczce prowadząca do zdalnego wykonania kodu daje dostęp do całej strony.

Zagrożenia i skutki

Piaskownica ogranicza szkody, ale nie jest nieprzepuszczalna. Błąd w jej implementacji albo w jądrze systemu pozwala na ucieczkę z piaskownicy (sandbox escape), czyli wykonanie kodu z pełnymi uprawnieniami. Pokrewnym problemem w świecie kontenerów jest ucieczka z kontenera. Dla napastnika oznacza to, że sam exploit na proces w piaskownicy nie wystarcza; potrzebuje jeszcze drugiej luki, która wyprowadzi kod poza jej granice.

Środowiska analizy mają inny słaby punkt: złośliwe oprogramowanie potrafi je rozpoznać. MITRE ATT&CK opisuje technikę T1497, w której napastnik sprawdza obecność artefaktów maszyny wirtualnej lub piaskownicy i po ich wykryciu zmienia zachowanie, ukrywa główne funkcje albo wstrzymuje pobranie kolejnych ładunków ^[5]. Próbka, która w analizie niczego nie robi, może więc zostać błędnie uznana za nieszkodliwą.

Dobre praktyki

• Ramki z cudzą treścią osadzaj z atrybutem sandbox i tylko potrzebnymi uprawnieniami ^[6].
• Nie łącz allow-scripts z allow-same-origin dla treści z tej samej domeny ^[6].
• Podejrzane pliki z przejętej strony analizuj w odizolowanym środowisku, nie na stacji administratora ^[4].
• Wynik analizy dynamicznej traktuj jako jedną z przesłanek, bo próbka mogła wykryć środowisko ^[5]; uzupełnij go skanerem złośliwego oprogramowania.

Historia i przykłady

NIST jako szeroko stosowany przykład aplikacji w piaskownicy podaje aplety Javy ^[2]. CERT Polska udostępnia na licencji GPL system DRAKVUF Sandbox do analizy behawioralnej złośliwych plików wykonywalnych; jest to jedno z głównych rozwiązań, z których serwis mwdb.cert.pl korzysta przy analizie próbek na Windows ^[4]. Zbudowano go na silniku DRAKVUF autorstwa Tamasa Lengyela, który monitoruje maszynę wirtualną z zewnątrz, techniką introspekcji maszyny wirtualnej (VMI), bez agenta w systemie gościa ^[4]. Według CERT Polska takie monitorowanie jest trudniejsze do wykrycia niż podejście z agentem ^[4].