CVE-2025-62725: Cum o comandă Docker Compose 'read-only' poate compromite host-ul tău

Versiunile Docker Compose anterioare 2.40.2 conțin o vulnerabilitate de path traversal cu severitate ridicată care permite suprascrierea arbitrară de fișiere și execuție de cod la distanță pe sistemul host. CVE-2025-62725 are un scor CVSS de 8.9, iar vectorul de exploatare este mai rău decât sugerează scorul. Atacatorii pot declanșa vulnerabilitatea prin comenzi pe care operatorii le presupun sigure și read-only, precum docker compose ps sau docker compose config. Vulnerabilitatea devine exploatabilă când mediul tău consumă artefacte OCI compose remote din registre, cataloage interne sau template-uri upstream. Aceasta include pipeline-uri CI, laptop-uri dezvoltatori și workspace-uri de dezvoltare cloud.

Runner-ele CI de producție, stațiile de lucru ale inginerilor și infrastructura de staging sunt expuse chiar acum dacă rulează build-uri Compose sub 2.40.2 și ating definiții compose remote. Suprafața de atac este oriunde tragi configurație compose de oriunde altundeva decât din fișiere locale verificate.

Cauza rădăcină: adnotările de încredere devin primitive de atac

Docker Compose suportă artefacte OCI compose remote ca alternativă la fișierele compose.yaml locale. În loc să stochezi compose.yaml local, poți să îl referențiezi ca artefact OCI într-un registru. Formatul artefactului folosește adnotări OCI pentru a specifica metadate precum calea fișierului compose, căile fișierelor de mediu și referințe extends. Cheile de adnotare relevante sunt com.docker.compose.file, com.docker.compose.envfile și com.docker.compose.extends.

Versiunile Compose vulnerabile au încredere în aceste valori de adnotare fără validare corespunzătoare. Când Compose rezolvă un artefact OCI remote, ia calea din adnotare, o îmbină cu directorul său de cache local și scrie conținutul artefactului pe acea cale calculată. Un atacator poate injecta secvențe de traversare de cale precum ../../../ în valorile adnotărilor. Compose scapă din directorul său de cache și scrie conținut controlat de atacator pe căi arbitrare de fișiere pe host, limitat doar de permisiunile utilizatorului care rulează procesul Compose. Presupunerea modelului de încredere era că metadatele artefactului OCI sunt sigure pentru că vin dintr-un registru pe care îl controlezi. Acea presupunere se strică când registrele sunt compromise, când tragi din cataloage publice fără verificare sau când otrăvirea lanțului de aprovizionare apare upstream.

Lanț de exploatare: de la scriere fișiere la acces complet sistem

Scrierea arbitrară de fișiere devine execuție de cod la distanță prin căi standard de post-exploatare. Cea mai directă este suprascrierea ~/.ssh/authorized_keys pentru a adăuga o cheie publică controlată de atacator, acordând acces SSH persistent la contul compromis. Fișierele de configurare shell precum ~/.bashrc, ~/.profile sau ~/.zshrc pot fi modificate pentru a executa comenzi malițioase la următoarea autentificare sau invocare shell. Unit-urile systemd de utilizator sau job-urile cron oferă execuție de cod programată sau la reboot.

Pe sistemele unde Compose rulează ca root sau cu privilegii ridicate, impactul se extinde la suprascrierea binarelor de sistem, configurația daemon-ului Docker sau Compose însuși. Atacatorul poate înlocui binarul docker-compose cu o versiune troianizată care execută payload-uri malițioase menținând în același timp funcționalitatea normală pentru a evita detectarea. Nodurile de producție înfruntă acest risc, dar țintele cu probabilitate mai mare sunt laptop-urile dezvoltatorilor, runner-ele CI/CD și workspace-urile de dezvoltare cloud care trag în mod rutinat artefacte compose remote din cataloage interne, template-uri publice sau repository-uri de infrastructură partajate. Runner-ele CI sunt deosebit de valoroase pentru că au adesea acces de scriere la repository-uri de cod, registre de artefacte și credențiale de deployment.

Suprafață de atac: pipeline-uri CI și otrăvire lanț aprovizionare

Exploatarea este o problemă de lanț de aprovizionare, nu o breșă de perimetru. Atacatorul nu are nevoie de acces la rețea la infrastructura ta sau credențiale la host-urile tale. Trebuie să poziționeze un artefact OCI compose malițios unde sistemele tale îl vor consuma. Un registru intern compromis care servește artefacte OCI compose către pipeline-ul tău CI permite înlocuirea sau injectarea de artefacte. Pipeline-urile care referențiază aceste artefacte prin tag sau digest vor trage versiunea otrăvită. Pipeline-ul rulează docker compose config sau docker compose up ca parte a workflow-ului său de build sau test, declanșând traversarea de cale și compromițând runner-ul CI.

Template-urile publice și proiectele starter amplifică raza de acțiune. Dezvoltatorii copiază frecvent comenzi docker compose din postări pe blog, documentație și repository-uri GitHub. Comenzi precum docker compose --file oci://example.com/starter/webapp:latest config par să efectueze inspecție read-only dar descarcă și procesează artefacte malițioase, suprascriind fișiere pe stația de lucru a dezvoltatorului. Utilizatorul crede că inspectează un fișier compose. În schimb, Compose descarcă artefactul, procesează adnotările malițioase și suprascrie fișiere pe stația lor de lucru.

Repository-urile interne "infrastructure as code" care conțin o singură referință OCI malițioasă expun fiecare echipă downstream. Multe organizații mențin repository-uri interne de fișiere compose, module terraform și template-uri de deployment pe care echipele le consumă ca blocuri de construcție. Dacă o referință de artefact OCI compose malițios este comisă într-unul din aceste repository-uri, fiecare echipă care trage din el devine expusă. Acest lucru este deosebit de periculos în organizațiile cu mecanisme automate de pull sau job-uri CI care reîmprospătează periodic dependențele template-urilor.

Domeniu: toate platformele, toate canalele de distribuție

Toate versiunile Docker Compose anterioare 2.40.2 sunt vulnerabile pe Linux, macOS și Windows. Aceasta include binare Compose standalone, Compose împachetat cu Docker Desktop și Compose instalat prin manageri de pachete de sistem. Vulnerabilitatea există în codul Compose însuși, deci metoda de distribuție nu contează.

Distribuțiile Linux downstream poate să nu fi adoptat încă release-ul 2.40.2. Un sistem care arată "up to date" prin apt, yum sau dnf nu garantează că versiunea patch-uită este instalată. Verifică versiunea efectivă Compose cu docker compose version și confirmă că raportează 2.40.2 sau mai mare. Imaginile container hărțuite și imaginile de bază minimale rămân adesea în urmă față de release-urile upstream, deci runner-ele CI bazate pe containere care folosesc imagini mai vechi rămân vulnerabile chiar dacă binarul Compose al host-ului este patch-uit. Utilizatorii Docker Desktop trebuie să actualizeze la release-uri care împachetează Compose 2.40.2 sau ulterior.

Detectare: inventar versiuni și monitorizare integritate fișiere

Începe cu inventarul de versiuni. Identifică fiecare locație unde Docker Compose este instalat: stații de lucru dezvoltatori, runner-e CI/CD, servere staging, noduri de producție și orice medii de build containerizate. Interogează versiunea instalată cu docker compose version și marchează orice raportează mai puțin de 2.40.2. Nu te baza pe metadatele managerului de pachete; verifică versiunea efectivă a binarului.

Pentru medii containerizate, inspectează imaginile de bază și containerele de build. Multe sisteme CI folosesc Docker-in-Docker sau bind-mount socket-ul Docker al host-ului. Aceste containere pot avea propriile instalări Compose care sunt independente de versiunea host-ului. Extrage binarul Compose din containerele în rulare sau straturile de imagine și verifică versiunea sa.

Revizuiește definițiile pipeline CI, fișierele compose și repository-urile de infrastructură pentru referințe la artefacte OCI remote. Caută scheme URI oci://, URL-uri de registru în contexte compose și workflow-uri care trag definiții din surse externe. Identifică nivelurile de încredere ale registrelor: registrele publice și cele cu controale de acces slabe reprezintă risc mai mare.

Monitorizează modificările de fișiere pe ținte de mare valoare: ~/.ssh/authorized_keys, fișiere RC shell, unit-uri systemd, job-uri cron și binare Docker sau Compose. Corelează timestamp-urile de modificare cu invocări Compose în istoricul shell, log-urile CI și auditarea sistemului. Modificările de fișiere la scurt timp după comenzi Compose care rezolvă artefacte remote indică potențială exploatare. Verifică directoarele de cache Docker și Compose pentru conținut neașteptat. Compose stochează artefactele OCI descărcate în cache-ul său, de obicei sub ~/.docker/compose sau căi similare. Exploatarea traversării poate lăsa artefacte sau fișiere temporare în locații neașteptate în afara directorului de cache.

Remediere: patch, restricționare, monitorizare

Remedierea primară este actualizarea Docker Compose la versiunea 2.40.2 sau ulterioară. Acest release include logică de validare a căii care previne secvențele de traversare să scape din directorul de cache. Descarcă versiunea reparată de pe pagina oficială de release Docker sau actualizează Docker Desktop la un build care include Compose 2.40.2 sau mai mare. Verifică actualizarea cu docker compose version după instalare.

Pentru mediile unde actualizarea imediată nu este fezabilă, mitigările operaționale reduc expunerea în timp ce patch-uirea este în progres. Cea mai eficientă mitigare este dezactivarea sau restricționarea utilizării artefactelor OCI compose remote. Dacă workflow-urile tale nu necesită definiții compose bazate pe OCI, elimină sau comentează orice referințe la URI-uri oci:// și registre externe din fișierele compose și definițiile pipeline CI. Aceasta elimină complet suprafața de atac.

Dacă artefactele OCI compose remote sunt necesare, impune o listă albă de registre de încredere. Configurează politici de rețea, reguli de firewall sau restricții la nivel Compose pentru a preveni rezolvarea artefactelor din surse neîncrezătoare. Registrele interne cu controale de acces puternice și logging de audit sunt preferabile registrelor publice. Implementează verificare de integritate pentru artefactele OCI folosind semnături criptografice sau pinning de digest pentru a asigura că artefactele nu au fost alterate.

Rulează Docker Compose ca utilizator non-privilegiat. Multe pipeline-uri CI și workflow-uri de automatizare rulează Compose ca root sau cu privilegii ridicate nenecesare. Restricționează execuția Compose la conturi de serviciu dedicate cu permisiuni minime de sistem de fișiere. Aceasta limitează amploarea suprascrierii de fișiere pe care un atacator o poate realiza chiar dacă exploatarea reușește. Pe stațiile de lucru dezvoltatori, evită rularea Compose cu sudo dacă nu este absolut necesar.

Adaugă monitorizare și alertare în jurul fișierelor critice. Implementează monitorizare de integritate a fișierelor pentru authorized_keys, fișiere RC shell, unit-uri systemd, job-uri cron și binare Docker sau Compose. Configurează alerte să se declanșeze când aceste fișiere sunt modificate, mai ales dacă modificările apar în afara ferestrelor programate de mentenanță sau deployment. Corelează alertele cu log-urile de invocare Compose pentru a identifica potențiale tentative de exploatare.

Pentru organizațiile cu infrastructură la scară largă, patch-uirea automată și managementul configurației sunt necesare. Folosește unelte precum Ansible, Chef sau Puppet pentru a împinge Compose 2.40.2 sau mai mare pe toate nodurile gestionate. Actualizează imaginile de bază container folosite în pipeline-urile CI pentru a include versiunea Compose patch-uită. Programează scanări pentru a verifica versiunile instalate și a marca sistemele care nu respectă conformitatea.

Acțiuni recomandate

• Inventar: Localizează fiecare loc unde Docker Compose rulează, incluzând mașini dezvoltatori, runner-e CI și host-uri de producție. Înregistrează versiunea instalată folosind docker compose version și marchează orice instalare raportând mai puțin de 2.40.2 ca vulnerabilă.
• Patch: Actualizează Docker Compose la 2.40.2 sau ulterior pe toate sistemele. Actualizează Docker Desktop la ultima versiune pe macOS și Windows pentru a primi remediere Compose împachetată. Verifică că actualizarea a reușit prin verificarea output-ului versiunii.
• Blocare: Restricționează sau dezactivează utilizarea artefactelor OCI compose remote din registre neîncrezătoare. Impune o listă albă de registre interne de încredere pentru sursele compose. Codifică aceste restricții în barierele de protecție ale platformei, template-urile pipeline CI și documentația internă pentru a preveni reintroducerea pattern-urilor vulnerabile.
• Monitorizare: Implementează monitorizare de integritate a fișierelor pe chei autorizate SSH, fișiere de configurare shell, unit-uri systemd și binare. Configurează alerte pentru modificări neașteptate și corelează-le cu log-urile de execuție Compose pentru a detecta tentative de exploatare.

Dacă infrastructura ta rulează workload-uri critice pe orchestrare de containere și ai nevoie de execuție operațională cu capacitate de validare și rollback pentru acest tip de modificări, ENGINYRING Servere Virtuale include configurare și întărire la nivel expert ca parte a serviciului administrat.