W narzędziu do zarządzania izolowanymi kontenerami Linux Docker vulnerabilność (), która w określonych okolicznościach umożliwia dostęp do środowiska hosta z kontenera, jeśli można uruchomić własne obrazy w systemie lub posiada się dostęp do działającego kontenera. Problem występuje we wszystkich wersjach Dockera i pozostaje nierozwiązany (zaproponowane, ale jeszcze nie przyjęte, , implementujące wstrzymywanie działania kontenera w czasie wykonywania operacji na systemie plików).
Vulnerabilność pozwala na wydobycie plików z kontenera do dowolnej części systemu plików hosta przy użyciu polecenia „docker cp”. Wydobycie plików odbywa się z uprawnieniami roota, co pozwala na odczyt lub zapis dowolnych plików w środowisku hosta, co wystarczy do uzyskania kontroli nad systemem hosta (na przykład można nadpisać /etc/shadow).
Atak może zostać przeprowadzony tylko w momencie, gdy administrator wykonuje polecenie „docker cp” dla skopiowania plików do kontenera lub z niego. W ten sposób atakujący musi w jakiś sposób przekonać administratora Dockera o konieczności wykonania tej operacji i przewidzieć używaną podczas kopiowania ścieżkę. Z drugiej strony atak może być przeprowadzony, na przykład, przy dostarczaniu przez usługi chmurowe narzędzi do kopiowania plików konfiguracyjnych do kontenera, zbudowanych przy użyciu polecenia „docker cp”.
Problem jest spowodowany niedopracowaniem w zastosowaniu funkcji , obliczającej absolutną ścieżkę w głównym systemie plików na podstawie relatywnej ścieżki, uwzględniającej lokalizację kontenera. W trakcie wykonywania polecenia „docker cp” powstaje krótkotrwały , w którym ścieżka została już zweryfikowana, ale operacja jeszcze nie została wykonana. Ponieważ kopiowanie odbywa się w kontekście głównego systemu plików hosta, w podanym czasie można zdążyć podmienić link na inną ścieżkę i zainicjować kopiowanie danych do dowolnego miejsca w systemie plików poza kontenerem.
Ponieważ czasowe okno wystąpienia wyścigu stanów jest silnie ograniczone w przygotowanym Podczas wykonywania operacji kopiowania z kontenera udało się przeprowadzić udany atak w mniej niż 1% przypadków podczas cyklicznego podmieniania linku symbolicznego w ścieżce używanej w operacji kopiowania (udało się przeprowadzić udany atak po około 10 sekundach ciągłych prób cyklicznego skopiowania pliku komendą „docker cp”).
Podczas wykonywania operacji kopiowania do kontenera można uzyskać powtarzalny atak związany z nadpisywaniem plików w systemie hosta w zaledwie kilku iteracjach. Możliwość ataku wynika z tego, że podczas kopiowania do kontenera stosowana jest koncepcja „chrootarchive”, zgodnie z którą proces archive.go wydobywa archiwum nie w chrootzie korzenia kontenera, lecz w chrootzie katalogu nadrzędnego docelowej ścieżki, kontrolowanej przez atakującego, i nie zatrzymuje przy tym działania kontenera (chroot jest używany jako sygnał do wykorzystania stanu wyścigu).
Źródło: opennet.ru
