In Toolkit voor het beheren van geïsoleerde Linux Docker-containers kwetsbaarheid (), waarmee u onder bepaalde omstandigheden toegang krijgt tot de hostomgeving vanuit een container als u de mogelijkheid heeft om uw images op het systeem te starten of als u toegang heeft tot een actieve container. Het probleem komt in alle versies van Docker voor en is nog steeds niet opgelost (voorgesteld, maar nog niet geaccepteerd, , die de ophanging van de container implementeert tijdens het uitvoeren van bewerkingen met de FS).
Door het beveiligingslek kunnen bestanden uit een container worden uitgepakt naar een willekeurig deel van het bestandssysteem van het hostsysteem bij het uitvoeren van de opdracht “docker cp”. Bestandsextractie wordt uitgevoerd met rootrechten, wat het mogelijk maakt om alle bestanden in de hostomgeving te lezen of te schrijven, wat voldoende is om controle over het hostsysteem te krijgen (u kunt bijvoorbeeld /etc/shadow overschrijven).
De aanval kan alleen worden uitgevoerd wanneer de beheerder het commando “docker cp” uitvoert om bestanden van of naar de container te kopiëren. De aanvaller moet de Docker-beheerder dus op de een of andere manier overtuigen van de noodzaak om deze bewerking uit te voeren en het pad te voorspellen dat bij het kopiëren wordt gebruikt. Aan de andere kant kan er bijvoorbeeld een aanval worden uitgevoerd wanneer clouddiensten tools bieden voor het kopiëren van configuratiebestanden naar een container, gebouwd met behulp van het commando “docker cp”.
Het probleem wordt veroorzaakt door een fout in de toepassing van de functie , dat het absolute pad in het hoofdbestandssysteem berekent op basis van het relatieve pad, rekening houdend met de plaatsing van de container. Tijdens het uitvoeren van de opdracht "docker cp" wordt een short-term , waarin het pad al is geverifieerd, maar de bewerking nog niet is uitgevoerd. Omdat het kopiëren wordt uitgevoerd in de context van het hoofdbestandssysteem van het hostsysteem, kunt u binnen een bepaalde tijdsperiode de link vervangen door een ander pad en het kopiëren van gegevens naar een willekeurige locatie in het bestandssysteem buiten de houder.
Omdat het tijdsbestek voor het optreden van een raceconditie bij een voorbereiding zeer beperkt is Bij het uitvoeren van kopieerbewerkingen vanuit een container was het in minder dan 1% van de gevallen mogelijk om een succesvolle aanval te realiseren door het cyclisch vervangen van een symbolische link in het pad dat bij de kopieerbewerking werd gebruikt (de succesvolle aanval werd uitgevoerd na ongeveer 10 seconden aan pogingen om het bestand continu in een lus te kopiëren met de opdracht “docker cp”).
Door een kopieerbewerking naar een container uit te voeren, kunt u in slechts enkele iteraties een herhaalbare bestandsoverschrijvingsaanval op het hostsysteem uitvoeren. De mogelijkheid van een aanval is te wijten aan het feit dat bij het kopiëren naar een container het concept “chrootarchive” wordt gebruikt, volgens welke het archive.go-proces het archief niet uitpakt in de chroot van de containerroot, maar in de chroot van de containerroot. bovenliggende map van het doelpad, beheerd door de aanvaller, en stopt de uitvoering van de container niet (chroot wordt gebruikt als teken om racevoorwaarden te misbruiken).
Bron: opennet.ru