Moda na Dockera opanowała świat devops, mimo że sama technologia konteneryzacji właściwie nie przyniosła niczego takiego, czego nie dają też standardowe technologie wirtualizacji – z tą jednak różnicą, że maszyny wirtualne rozwiązały dawno temu problemy, z którymi Docker wciąż się zmaga. Widać to choćby po regularnie odkrywanych lukach w bezpieczeństwie. Najnowszą z nich trudno będzie naprawić, jak z branżowych dyskusji wynika, w najlepszym razie zagrożenie można tylko złagodzić.
Wszystkie wersje Dockera okazują się być podatne na stan hazardu (race condition), który pozwala napastnikowi uzyskać możliwość odczytania i zapisania dowolnego pliku w systemie hosta. Odkrywca luki, Aleksa Sarai z Suse, wydał już przykładowe exploity. Co prawda ich skuteczność nie przekracza 1%, ale w praktyce oznacza, że już najdalej po 10 sekundach skrypt uruchamiający atak w pętli uzyska dostęp do plików poza kontenerem, włącznie z ich nadpisaniem.
Po ścieżce do roota
Błąd, który na to pozwala, określa się jako TOCTOU: time-to-check-time-to-use: oferuje napastnikom możliwość modyfikowania ścieżek do zasobów po ich rozwiązaniu, ale zanim przydzielony program zacznie działać na danym zasobie.
W rdzeniu Dockera wykorzystywana jest funkcja FollowSymlinkInScope. Służy ona bezpiecznemu rozwiązaniu określonej ścieżki poprzez traktowanie procesów tak, jakby znajdowały się one wewnątrz kontenera. I ta właśnie funkcja jest podatna na atak TOCTOU.
Na rozwiązanej ścieżce dostępu nie dochodzi do operacji natychmiastowo, raczej jak wyjaśnia Sarai, jest ona przekazywana dookoła, a dopiero nieco później wykorzystywana. Napastnik może więc przewidzieć to opóźnienie i dodać symboliczną ścieżkę, która doprowadzi do rozwiązania na hoście z uprawnieniami roota.
Pozwala na to narzędzie docker cp, przeznaczone do kopiowania plików między kontenerem a lokalnym systemem plików. Było one wykorzystywane już w dwóch innych lukach, i jak zauważa inżynier z Suse, nie ma właściwie sensownego sposobu na uniemożliwienie tego typu ataku. Co najwyżej można nie dopuścić do uruchamiania docker cp na działających kontenerach – ale to pomoże tylko w tym ataku poprzez FollowSymlinkInScope.
Jeśli więc demon Dockera nie został ograniczony np. regułami AppAror, kontener będzie miał swobodny dostęp do systemu plików hosta. Na pewno działa to na redhatowych systemach z domyślną konfiguracją SELinuksa (RHEL/CentOS/Fedora).
Niełatwo temu zaradzić
Jak do tej pory nie zaradzono temu zagrożeniu, w dyskusji na Hacker News przedstawiono kilka sposobów na ograniczenie zagrożenia, ale wymagałyby one daleko idących zmian w samym rdzeniu Dockera i raczej nie ma co się spodziewać ich wdrożenia.
Zgłoszona już za to została łatka, która zatrzymuje działanie kontenera przy dostępie do plików. Nie powstrzyma to wszystkich ataków, ale uważa się, że jest obroną przynajmniej przeciwko tym najbardziej typowym.
Czy to odkrycie cokolwiek zmieni? Pewnie nie. Docker jest zbyt modny, zbyt dużo pieniędzy za nim stoi, panuje przekonanie, że z każdą luką poradzi sobie kolejna aktualizacja.
