W zestawie narzędzi do zarządzania izolowanymi kontenerami Docker systemu Linux słaby punkt (), który w pewnych okolicznościach umożliwia dostęp do środowiska hosta z kontenera, jeśli masz możliwość uruchomienia obrazów w systemie lub masz dostęp do działającego kontenera. Problem pojawia się we wszystkich wersjach Dockera i pozostaje nierozwiązany (zaproponowano, ale jeszcze nie zaakceptowano, , który realizuje zawieszenie kontenera podczas wykonywania operacji z FS).
Luka umożliwia wyodrębnienie plików z kontenera do dowolnej części systemu plików systemu hosta podczas wykonywania polecenia „docker cp”. Ekstrakcja plików odbywa się z uprawnieniami roota, co umożliwia odczyt lub zapis dowolnych plików w środowisku hosta, co wystarczy do przejęcia kontroli nad systemem hosta (możesz na przykład nadpisać plik /etc/shadow).
Atak może zostać przeprowadzony tylko wtedy, gdy administrator wykona polecenie „docker cp”, aby skopiować pliki do lub z kontenera. Zatem atakujący musi w jakiś sposób przekonać administratora Dockera o konieczności wykonania tej operacji i przewidzieć ścieżkę używaną podczas kopiowania. Z drugiej strony atak można przeprowadzić np. gdy usługi chmurowe udostępniają narzędzia do kopiowania plików konfiguracyjnych do kontenera zbudowanego za pomocą polecenia „docker cp”.
Problem jest spowodowany błędem w zastosowaniu funkcji , który oblicza ścieżkę bezwzględną w głównym systemie plików na podstawie ścieżki względnej, biorąc pod uwagę położenie kontenera. Podczas wykonywania polecenia „docker cp”, krótkotrwały , w którym ścieżka została już zweryfikowana, ale operacja nie została jeszcze wykonana. Ponieważ kopiowanie odbywa się w kontekście głównego systemu plików systemu hosta, w określonym czasie można zastąpić łącze inną ścieżką i zainicjować kopiowanie danych do dowolnej lokalizacji w systemie plików poza systemem plików pojemnik.
Ponieważ okno czasowe wystąpienia warunków wyścigu jest bardzo ograniczone w przypadku przygotowanym Podczas wykonywania operacji kopiowania z kontenera udało się osiągnąć udany atak w mniej niż 1% przypadków przy cyklicznym zastępowaniu dowiązania symbolicznego w ścieżce użytej w operacji kopiowania (udany atak został przeprowadzony po około 10 sekundach prób aby w sposób ciągły kopiować plik w pętli za pomocą polecenia „docker cp”).
Wykonując operację kopiowania do kontenera, możesz w ciągu zaledwie kilku iteracji przeprowadzić powtarzalny atak polegający na nadpisaniu pliku na systemie hosta. Możliwość ataku wynika z faktu, że podczas kopiowania do kontenera wykorzystywana jest koncepcja „chrootarchive”, zgodnie z którą proces Archive.go rozpakowuje archiwum nie do chroot katalogu głównego kontenera, ale do chroot katalog nadrzędny ścieżki docelowej, kontrolowany przez atakującego i nie wstrzymuje wykonywania kontenera (chroot jest używany jako znak do wykorzystania warunków wyścigu).
Źródło: opennet.ru
