Docker ontdekt dat vijf jaar oude fix voor kritiek lek ontbreekt in software

Docker heeft ontdekt dat een beveiligingsupdate voor een vijf jaar oude kwetsbaarheid niet standaard wordt meegeleverd in nieuwere versies van de software. Via de kwetsbaarheid kunnen ongeautoriseerde acties uitgevoerd worden, zoals het verhogen van de rechten.

Docker is de ontwikkelaar van de gelijknamige software voor bestandssysteemvirtualisatie. De kwetsbaarheid, die al in 2018 ontdekt werd, zit in het standaard autorisatiemodel van Docker. Gebruikers die toegang hebben tot Docker daemon kunnen ieder Docker-commando uitvoeren. Voor verbeterde toegangscontrole kunnen autorisatieplug-ins gebruikt worden die verzoeken aan Docker daemon beoordelen op basis van verificatie en de context van het commando. Aanvallers blijken die plug-ins echter te kunnen omzeilen via een speciaal gemaakt api-verzoek. De ernst van de kwetsbaarheid wordt beoordeeld met een 10.0 op een schaal van 1 tot 10.

De kwetsbaarheid werd begin 2019 gedicht in Docker Engine v18.09.1. Docker heeft nu echter ontdekt dat die fix niet meegenomen wordt in latere versies van de Engine, schrijft het bedrijf op zijn website. Daardoor is regressie ontstaan.

Het probleem werd afgelopen april ontdekt en raakt alle versies die voor 23 juli 2024 zijn uitgekomen. Inmiddels is een nieuwe versie van Docker Engine uitgebracht, versie 27.1.1, waarin de patch wel weer is meegenomen. Deze versie van Docker Engine wordt ook opgenomen in Docker Desktop v4.33.

Reacties (29)

[Cyb]

Om onder andere deze reden is Podman ontwikkeld, met rootless containers. Waar de Docker daemon onder root draait. Inmiddels heeft Docker ook de mogelijkheid om Rootless te draaien, maar bij Podman is security van het begin af aan één van de core ideeen.
Doordat Podman standaard rootless is, is de impact van dergelijke vulnerabilities minder erg.
(Verder is Podman open source i.t.t. het product dat Docker op zijn site aanbiedt als Docker Desktop, ondanks dat Docker Engine open source is.)

[Reactie gewijzigd door Cyb op 25 juli 2024 11:32]

[RobertMe]

Volgens mij niet aan de orde. Hoe ik het lees kun je de Docker daemon laten valideren of een actie door een API client uitgevoerd mag worden. En de authenticatie op de API is waar het mis gaat. Het is dus geen exploit waarmee je direct root toegang krijgt (wel indirect doordat je containers kunt starten die als root draaien en je via die weg het systeem vast kunt overnemen).

Bijvoorbeeld Traefik, een reverse proxy, kun je gebruiken in combinatie met Docker om automatisch een proxy op te zetten naar services die in Docker draaien. Hiervoor moet je Traefik toegang geven tot de Docker daemon / API. Dit zodat Traefik kan monitoren of er containers gestart worden en bv welke labels op die containers zitten (om te bepalen of die deze service moet exposen en allemaal andere instellingen). Echter is het traditioneel zo dat Traefik vervolgens toegang heeft tot de volledige Docker API. En dus ook containers kan starten en wat dan ook. En er is dus, blijkbaar, een authenticatie plugin waarmee je Docker dus kunt configureren dat "API client Traefik" alleen maar draaiende containers mag inspecteren en events mag monitoren. Maar dus niet nieuwe containers mag aanmaken. Alleen zit er nu dus al 5 jaar een bug in dat authenticatie deel waardoor dit vrij makkelijk te omzeilen is.

En vergelijken met Podman in deze gaat sowieso niet. Omdat Podman in de basis al anders werkt. Podman heeft helemaal geen daemon die alle containers beheert en (dus) is er ook geen API die je kunt aanspreken om dezr zaken te doen en dus kan Podman ook niet lek zijn om dit vlak. Immers kan Podman geen lekke API hebben omdat er helemaal geen API is.
Waar de docker CLI de Docker daemon via zijn API aanspreekt om een container te starten is het bij Podman direct het podman commando dat een container start, daar komt geen API aan te pas. En bv de auto discovery functionaliteit van Traefik kan op Podman ook niet. Immers is er geen centraal punt waar alke containers geregistreerd staan.

Sidenote: AFAIK heeft Podman wel een alternatieve implementatie van wat de Docker daemon zou zijn. Zodat Docker compatible tools (/API clients) ook met Podman kunnen babbelen. En deze alternatieve "Docker daemom" zou dus exact hetzelfde lek kunnen bevatten (als het authenticatie model daar uberhaupt in zit). Enige verschil is dan dat je bij de Podman variant mogelijk geen containers als root kunt draaien terwijl dat bij Docker semi standaard het geval is.

[Ghoelian]

Immers is er geen centraal punt waar alke containers geregistreerd staan.

podman heeft nog wel het ps command, waarmee ik gewoon al mijn draaiende en gestopte containers kan listen. Dat moet dan toch ergens geregistreerd staan?

[Reactie gewijzigd door Ghoelian op 25 juli 2024 15:36]

[HollowGamer]

Ik volg het ook niet helemaal. Als je namelijk de Podman service herstart, breng je ook alle containers down. Dat is gewoon de Podman engine. Die beheerd ook het netwerk, volumes, etc.

Ook het Docker voorbeeld volg ik niet. Zover ik weet is podman-docker package, een soort helper om Docker commandos te herschrijven naar Podman. Je hebt ook podman-compose. Die doet niets met Docker zelf, het herschrijft de input van de yaml, naar de correcte syntax voor Podman.

Overigens raad ik iedereen Podman aan, ook met Quadlet. Dat werkt erg goed en fijn, aangezien je het beheerd met systemd.

Dat Podman geschreven is voor rootless klopt ook niet. Het kan beide, maar voor rootless zul je toch echt wel nog wat dingen moeten doen op het OS, en rootless heeft ook weer nadelen. Het wordt bestempeld als veiliger, maar het praat over een kernel bus, waar nog altijd veel over te doen is.

[daily.data.inj]

Via de kwetsbaarheid kunnen ongeautoriseerde acties uitgevoerd worden, zoals het verhogen van de rechten.

Volgens info op docker website ben je alleen affected als je ook gebruikt maakt van authorization plugins.

Who is impacted?
Users of Docker Engine v19.03.x and later versions who rely on authorization plugins to make access control decisions.

Geeft toch net een iets andere scope aan het artikel.

[HollowGamer]

Maak je daar dan geen gebruik van als je images pulled van hun repo? Niet publiekelijk, maar bedoel die achter een wall zitten.

[GarBaGe]

Docker is wat verwarrend.
Het is zowel het formaat van de container, als OOK de runtime engine, als OOK tooling om Docker images te managen
In dit geval zit het probleem in de Docker Engine, dus NIET in de images (of tooling)

[Some12]

Is het formaat van de container niet OCI?

[RobertMe]

Ja en nee. Toen Docker heel populair werd en er alternatieven kwamen (zoals Kubernetes) die ook met Docker images overweg konden zijn vanuit Docker verschillende zaken overgedragen naar de opgerichte "Open Container Initiative" (aka: OCI). Waaronder dus het image format. En de container runtime, containerd, is volgens mij ook als code gedoneerd aan OCI.

Dus eerst deed Docker gewoon wat ze zelf wilden. Zij hadden bv het image format intern verzonnen, en konden hier ook wijzigingen aan doen "als ze daar zin in hadden". Maar op een gegeven moment hebben ze dit gestandaardiseerd samen met andere partijen die hier gebruik van willen maken.

Dus in principe: "Docker image" is exact hetzelfde als "OCI image", alleen een andere naam.

Of een ander, vergelijkbaar, voorbeeld: "(Microsoft) Word document". Iedereen weet wat je bedoelt, terwijl het effectief een implementatie is van de "Open Office XML" standaard, die Microsoft zelf heeft opgesteld en door een standaard orgaan beheerd wordt. (En de concurrenten zoals LibreOffice juist een andere standaard gebruiken, OpenDocument Format )

[Reactie gewijzigd door RobertMe op 25 juli 2024 11:59]

[HollowGamer]

Ik snap dat het niet de image zelf zit.

Het ging mij erom dat je die kunt laten builden upstream, en dan dus kunt binnenhalen via de registry.

Volgens mij gaat dit namelijk over dit auth protocol?

[JustFogMaxi]

Oftewel, containerd, de runtime.

[RobertMe]

Ik denk ook niet containerd? Containerd zit volgens mij nog lager. De docker daemon, waar het hier over gaat, is het management deel om alles te beheren en daar zit het autorisatie stuk in. En voor elke draaiende container wordt IIRC een containerd proces gestart. Dus dockerd spawnd containerd processen (als je "docker run ..." / "docker start ..." doet), maar ook alternatieve OCI compatible container runtimes gebruiken containerd, maar dus niet dockerd.

En het lek zit zoals ik het lees dan in dat deel dat de opdrachten afhandelt en uitvoert. Dus dan dockerd. Want als je (bv) de docker CLI gebruikt doet die een API call naar de Docker daemon. De Docker daemon autoriseert dan of je dat commando mag uitvoeren (bv dus het commando "maak en start een container op basis van image X"), en als je die actie mag doen wordt die pas uitgevoerd. En in het geval van een "start" zal dat dus betekenen dat een containerd proces wordt gespawnd.

[Hatsjoe]

De Docker Engine, hetgeen wat geraakt is door deze kwetsbaarheid is de laag die bovenop containerd draait. De kwetsbaarheid zit dus niet in containerd, maar in de Docker Engine laag daarboven.

[StefanJanssen]

Wat zou de oorzaak zijn? Merge conflict waarbij een medewerker de fix eruit heeft gehaald? of zouden ze de fix als "hotfix" op een release branch gedaan hebben en deze branch nooit terug gebracht naar de main branch?

[RobertMe]

Grootste kans lijkt mij "hotfix die niet terug is gemerged". Mergen zullen ze wel vaker doen (want met Git werk je nu eenmaal vaak met (feature / bugfix) branches) en conflicten zullen dus ook met enige regelmaat voorkomen. Dan zou het wel heel pijnlijk zijn als ze net een merge conflict verkeerd oplossen bij een kritieke security fix en we verder nooit lezen van slechte merges die tot bugs leiden.

[Hobbit13]

Het is wel gek dat er geen verificatie test op deze bugfix in de release procedure zit. Je zou verwachten dat alle kritieke bugs wel een dedicated test krijgen, om regressie te voorkomen.

[riemer1990]

Moet de nieuwe test wel mee-gemerged zijn

[HollowGamer]

Verzoek van de NSA of Israël, dat lees ik net op FB.

Maar dit is gewoon een menselijke fout. Daar is niets fout aan, dat gebeurt nu eenmaal. De hoop is alleen dat het niet misbruik is geworden.

[SunnieNL]

Menselijke fout die niemand is opgevallen in 5 jaar tijd
Tot zo ver Open Source is altijd veiliger omdat er altijd wel mensen meekijken in de code.

[101br03k]

En het was natuurlijk eerder ontdekt als het closed source was?

[SunnieNL]

Dat zeg ik niet en zul je mij ook nooit horen beweren, net als ik nooit beweer dat opensource zoveel veiliger is. Echter, velen hier melden wel dat opensource veiliger is omdat de code openbaar is.
Dat heb ik echter altijd bestreden, maar op de een of andere manier blijft die gedachte bij veel mensen hangen.

[Ghoelian]

Open source software kan veiliger zijn, als je het ook echt audit. Als niemand dat doet heb je er natuurlijk niks aan.

[HollowGamer]

In de Linux kernel zijn soms fouten die er al vanaf het begin inzitten. Ook laatst ook een merge van geweest (15 year old bug) en je wilt niet weten hoe vaak weer iets gerevert of opnieuw moet.

Zelfs met een volledige automatische test suite, heb je soms gewoon pech. Snap dat mensen niet blij zijn, maar dit kan Apple of MS ook gebeuren (en dat is al vaker geweest - zoals dat een wekker niet afging of schrikkeljaar enzo). Het verschil is dat dit juist in een ring zit waarbij dit 'fataal' kan zijn, eigenlijk zou het ook eerst naar MS moeten voor ondertekening/verificatie.

Het zijn nog altijd mensen die achter de knoppen zitten, die maten nu eenmaal weleens een fout. En Windows is gewoon zo slecht geschreven, dat alles fout kan gaan. Met Linux kun je gewoon tijdens de boot, een module uitschakelen.

[Reactie gewijzigd door HollowGamer op 25 juli 2024 16:05]

[moonlander]

Het probleem werd afgelopen april ontdekt en raakt alle versies die voor 23 juli 2024

Dan is het wel weer jammer dat het zolang op zich moet wachten om alsnog de fix te implementeren.

[gimbal]

Te releasen, wanneer de (her-)implementatie is voltooid dat kunnen we niet zeggen. Het zou wel interessant zijn om hier een post-mortem van te lezen waar het allemaal fout ging want de merge conflict is zeker niet het enige wat hier fout is gelopen.

De timing is het meest pijnlijke. Ze waren waarschijnlijk aan het voorbereiden om dit zo genuanceerd mogelijk wereldkundig te maken... en dan gebeurd even Crowdstrike tussendoor om de hele wereld in een slecht humeur te brengen. Ik voel plaatsvervangende pijn.

[watercoolertje]

en dan gebeurd even Crowdstrike tussendoor om de hele wereld in een slecht humeur te brengen.

Ik denk zelf eerder het tegenovergestelde juist. Er is wel wat aan de hand (er zijn fouten gemaakt) maar er zijn vrijwel geen gevolgen want de fix is al uit en de halve wereld heeft er niet door plat gelegen zoals met Crowdstrike

Dus ik zie sowieso niet hoe je die zaken met elkaar in verband trekt maar imo is het docker-issue echt 10000x kleiner en dus eigenlijk gewoon niet zo boeiend, in vergelijking met Crowdstrike waar bijna iedereen daadwerkelijk hinder door heeft gehad.

[Reactie gewijzigd door watercoolertje op 25 juli 2024 10:48]

[SunnieNL]

De fix heeft blijkbaar 5 jaar lang niet in het product gezeten. Dus ik vind het wel een uitspraak om dan te zeggen dat er vrijwel geen gevolgen zijn. Wie weet hoe lang dit al misbruikt wordt zonder dat we het weten omdat we dachten dat de fix al in het product zat?

[MuizUnattended]

"Users of Docker Engine v19.03.x and later versions who do not rely on authorization plugins to make access control decisions and users of all versions of Mirantis Container Runtime are not vulnerable," Docker's Gabriela Georgieva said.

"Users of Docker commercial products and internal infrastructure who do not rely on AuthZ plugins are unaffected."

[Reactie gewijzigd door MuizUnattended op 25 juli 2024 12:46]

[fuse.core]

Maar 2019 was niet... oh