CVE-2020-15257

Riepilogo

containerd è un runtime container standard di settore ed è disponibile come daemon per Linux e Windows. In containerd precedente alle versioni 1.3.9 e 1.4.3, l'API containerd-shim è esposta in modo improprio ai container di rete host. I controlli di accesso per il socket API dello shim verificavano che il processo di connessione avesse un UID effettivo pari a 0, ma non limitavano altrimenti l'accesso al socket del dominio Unix astratto. Ciò avrebbe consentito a container dannosi in esecuzione nello stesso namespace di rete dello shim, con un UID effettivo pari a 0 ma con privilegi altrimenti ridotti, di causare l'esecuzione di nuovi processi con privilegi elevati. Questa vulnerabilità è stata corretta in containerd 1.3.9 e 1.4.3. Gli utenti dovrebbero aggiornare a queste versioni appena vengono rilasciate. Va notato che i container avviati con una versione precedente di containerd-shim devono essere arrestati e riavviati, poiché i container in esecuzione continueranno a essere vulnerabili anche dopo un aggiornamento. Se non offri la possibilità a utenti non fidati di avviare container nello stesso namespace di rete dello shim (tipicamente il namespace di rete "host", ad esempio con `docker run --net=host` o `hostNetwork: true` in un pod Kubernetes) ed eseguirli con un UID effettivo pari a 0, non sei vulnerabile a questo problema. Se stai eseguendo container con una configurazione vulnerabile, puoi negare l'accesso a tutti i socket astratti con AppArmor aggiungendo una riga simile a `deny unix addr=@**,` alla tua policy. È buona pratica eseguire i container con un insieme ridotto di privilegi, con un UID diverso da zero e con namespace isolati. I manutentori di containerd sconsigliano vivamente di condividere i namespace con l'host. Ridurre l'insieme dei meccanismi di isolamento utilizzati per un container aumenta necessariamente i privilegi di quel container, indipendentemente dal runtime container utilizzato per eseguirlo.

• abstractshimmerPoC