Dev / CodingNieuwsAI-generated

Cloudflare dicht lek waarmee klanten restdata uit containers van anderen konden lezen

Cloudflare heeft een kwetsbaarheid gedicht waarmee klanten restanten van data uit containers van andere klanten konden terughalen. Het bedrijf beschrijft het probleem en de afhandeling zelf in een post-mortem op zijn blog; BleepingComputer berichtte er deze week over.

Eén configuratievlag

De oorzaak is opvallend klein. Cloudflare Containers en Cloudflare Sandboxes draaien op gedeelde opslagpools die gebruikmaken van dm-thin, de thin-provisioninglaag van Linux device mapper. In die configuratie stond skip_block_zeroing aan. Die optie doet precies wat de naam zegt: nieuw toegewezen blokken worden niet met nullen overschreven voordat ze beschikbaar komen.

Blokken zijn 64 KiB groot. Schreef een nieuwe container minder dan zo'n volledig blok, dan bleef de rest van dat blok gevuld met wat de vorige gebruiker er had achtergelaten. Dat restant was uitleesbaar. Het overslaan van dat nulstellen is een bewuste prestatiekeuze — je vermijdt schrijfwerk bij het alloceren — maar in een omgeving met meerdere klanten op dezelfde host vervalt daarmee de isolatie tussen die klanten.

Wat er te vinden was, ging verder dan willekeurige bytes. Cloudflare noemt directorystructuren, databasepagina's, "structureel complete SQLite-databases" en metadata van bestandssystemen uit containers van andere klanten op dezelfde host. BleepingComputer noemt op basis van het onderzoek ook Chromium-profielen, .env-bestanden en bestanden met inloggegevens. De onderzoekers troffen restmateriaal aan op 18 van de 24 geteste containerplaatsingen, verspreid over 20 van de 22 nodes.

Er waren grenzen. Actief aangekoppelde schijven waren niet te lezen en data van andere klanten was niet te wijzigen. De kwetsbaarheid was wel bereikbaar voor iedere klant met een betaald Workers-account — geen bijzondere positie dus.

Tijdlijn

De melding kwam op 4 september via HackerOne binnen, van beveiligingsonderzoeker Oren Yomtov van Accomplish. Cloudflare bevestigde het incident diezelfde dag ruim drie uur later, en had de fixes dezelfde avond samengevoegd en de uitrol gestart. Op 7 september was die uitrol klaar en begon het opruimen. Op 19 september waren alle snapshots van vóór de mitigatie gewist.

De oplossing is het weghalen van skip_block_zeroing uit de configuratie. Daarnaast heeft Cloudflare alle draaiende containerschijven en gecachte image-snapshots die vóór de mitigatie zijn gemaakt uit gebruik genomen. Klanten hoefden zelf niets aan te passen.

Cloudflare zegt geen aanwijzingen te hebben gevonden dat iemand anders deze aanvalsroute heeft misbruikt.

Waarom dit relevant is

Wie code van anderen op zijn infrastructuur laat draaien, koopt het probleem van hergebruikte opslag erbij. De scheiding tussen klanten zat hier niet in het rechtenmodel of in de netwerklaag, waar de aandacht meestal naartoe gaat, maar in de vraag of een blok schoon was voordat het opnieuw werd uitgedeeld. Dat geldt net zo goed voor wie zelf containers op gedeelde volumes met thin provisioning inricht: een prestatie-optimalisatie op opslagniveau kan een isolatiegrens zijn die je dacht elders te hebben geregeld.

Cloudflare dicht lek waarmee klanten restdata uit containers van anderen konden lezen — Wallieweb