Nedávno se stalo známým skrz příspěvek na blogu, výsledky testovacích nástrojů k identifikaci zranitelných míst žádná oprava a identifikace bezpečnostních problémů v izolovaných obrázcích kontejneru Docker.
Test ukázal, že 4 ze 6 skenerů známé Docker obrázky měl kritické zranitelnosti který umožnil zaútočit na samotný skener a spustit jeho kód v systému, v některých případech (například pomocí Snyku) s oprávněními root.
Za útok útočníkovi stačí začít kontrolovat jeho Dockerfile nebo manifest.json, který zahrnuje speciálně naformátovaná metadata, nebo vložte soubory podfile a gradlew dovnitř obrázku.
Podařilo se nám připravit zneužít prototypy pro systémy WhiteSource, Snyk, Fossa a ukotvení.
El paquete Clair, původně napsáno s ohledem na bezpečnost, ukázal nejlepší zabezpečení.
V balíčku Trivy nebyly identifikovány žádné problémy a ve výsledku se dospělo k závěru, že skenery kontejnerů Docker by měly být spuštěny v izolovaných prostředích nebo použity pouze k ověření jejich vlastních obrazů, a také být opatrní při připojování těchto nástrojů k automatizovaným systémům nepřetržité integrace.
Tyto skenery dělají složité a náchylné k chybám. Zabývají se ukotvitelným panelem, extrahováním vrstev / souborů, interakcí se správci balíků nebo analýzou různých formátů. Bránit je, i když se snaží vyhovět všem případům použití pro vývojáře, je velmi obtížné. Podívejme se, jak se to různé nástroje snaží a zvládají:
Skóre odpovědného zveřejnění odráží můj osobní názor: Myslím si, že je důležité, aby prodejci softwaru byli vnímaví k bezpečnostním problémům, které jim byly nahlášeny, byli upřímní a transparentní ohledně zranitelností a zajistili, aby lidé, kteří používají jejich produkty, byli řádně informováni, aby mohli činit rozhodnutí o aktualizaci. To zahrnuje nejdůležitější informace, které aktualizace obsahuje změny relevantní pro zabezpečení, otevření CVE pro sledování a komunikaci o problému a potenciální upozornění vašich zákazníků. Myslím, že je obzvláště rozumné předpokládat, že jde o produkt CVE, který poskytuje informace o chybách zabezpečení v softwaru. Rovněž mě uklidňuje rychlá reakce, přiměřené časy oprav a otevřená komunikace s osobou, která útok nahlásila.
Ve společnostech FOSSA, Snyk a WhiteSource tato chyba zabezpečení souvisela s voláním externímu správci balíků určit závislosti a umožnit vám organizovat provádění kódu zadáním dotykových a systémových příkazů v souborech gradlew a podfile.
En Snyk a WhiteSource také našli chybu zabezpečení spojenou s příkazy spouštěcího systému organizace, která analyzovala soubor Dockerfile (například v Snyku přes Dockefile můžete nahradit nástroj ls (/ bin / ls) způsobený skenerem a ve WhiteSurce můžete kód nahradit pomocí argumentů ve formě „echo“; tap / tmp / hacked_whitesource_pip; = 1.0 '«).
V Anchore byla zranitelnost způsobena použitím nástroje skopeo pracovat s obrázky ukotvitelných panelů. Operace byla omezena na přidání parametrů formuláře „» os »:« $ (touch hacked_anchore) »“ do souboru manifest.json, které jsou nahrazeny při volání skopeo bez řádného úniku (byly odstraněny pouze znaky «; & < > ", Ale konstrukt" $ () ").
Stejný autor provedl studii o účinnosti detekce zranitelnosti není oprava prostřednictvím bezpečnostních skenerů dockerových kontejnerů a úroveň falešných poplachů.
Kromě autora tvrdí, že několik z těchto nástrojů přímo použijte správce balíčků k vyřešení závislostí. Díky tomu je obzvláště obtížné bránit. Někteří správci závislostí mají konfigurační soubory, které umožňují zahrnutí kódu prostředí.
I když jsou tyto jednoduché způsoby nějak zvládnuty, volání těchto správců balíčků bude nevyhnutelně znamenat vyplacení peněz. To, mírně řečeno, neusnadňuje obhajobu žádosti.
Výsledky testů 73 obrázků obsahujících chyby zabezpečení známé, stejně jako vyhodnocení účinnosti pro stanovení přítomnosti typických aplikací v obrazech (nginx, kocour, haproxy, gunicorn, redis, rubín, uzel), lze konzultovat v rámci zveřejněné publikace Na následujícím odkazu.