I Toolkit til håndtering af isolerede Linux Docker-containere sårbarhed (), som under visse omstændigheder giver dig adgang til værtsmiljøet fra en container, hvis du har mulighed for at starte dine billeder på systemet eller med adgang til en kørende container. Problemet opstår i alle versioner af Docker og forbliver uløst (foreslået, men endnu ikke accepteret, , som implementerer suspensionen af containeren, mens der udføres operationer med FS).
Sårbarheden gør det muligt at udtrække filer fra en container til en vilkårlig del af værtssystemets filsystem, når kommandoen "docker cp" udføres. Filudtrækning udføres med root-rettigheder, hvilket gør det muligt at læse eller skrive alle filer i værtsmiljøet, hvilket er nok til at få kontrol over værtssystemet (f.eks. kan du overskrive /etc/shadow).
Angrebet kan kun udføres, når administratoren udfører kommandoen "docker cp" for at kopiere filer til eller fra containeren. Således skal angriberen på en eller anden måde overbevise Docker-administratoren om behovet for at udføre denne handling og forudsige stien, der bruges ved kopiering. På den anden side kan et angreb udføres, for eksempel når cloud-tjenester leverer værktøjer til at kopiere konfigurationsfiler til en container, bygget ved hjælp af kommandoen "docker cp".
Problemet er forårsaget af en fejl i anvendelsen af funktionen , som beregner den absolutte sti i hovedfilsystemet baseret på den relative sti under hensyntagen til placeringen af beholderen. Mens du udfører kommandoen "docker cp", en kortsigtet , hvor stien allerede er blevet bekræftet, men handlingen endnu ikke er blevet udført. Da kopieringen udføres i konteksten af værtssystemets hovedfilsystem, kan du inden for et bestemt tidsrum nå at erstatte linket med en anden sti og starte kopiering af data til en vilkårlig placering i filsystemet uden for beholder.
Da tidsvinduet for at en løbstilstand opstår er meget begrænset i en forberedt Når du udfører kopieringshandlinger fra en container, var det muligt at opnå et vellykket angreb i mindre end 1 % af tilfældene, når du cyklisk erstattede et symbolsk link i stien, der blev brugt i kopieringsoperationen (det vellykkede angreb blev udført efter ca. 10 sekunders forsøg for kontinuerligt at kopiere filen i en løkke med kommandoen "docker cp").
Ved at udføre en kopieringsoperation ind i en container kan du opnå et repeterbart filoverskrivningsangreb på værtssystemet på blot et par iterationer. Muligheden for angreb skyldes, at når der kopieres ind i en container, bruges "chrootarchive"-konceptet, hvorefter archive.go-processen trækker arkivet ikke ind i chroot af containerroden, men ind i chroot af overordnet bibliotek for målstien, kontrolleret af angriberen, og stopper ikke udførelsen af containeren (chroot bruges som et tegn til at udnytte raceforhold).
Kilde: opennet.ru
