CVE-2020-15257

containerd è un runtime di container standard del settore ed è disponibile come daemon per Linux e Windows. In containerd prima delle versioni 1.3.9 e 1.4.3, l'API containerd-shim è stata esposta in modo improprio ai container sulla rete host. I controlli di accesso per la socket API dello shim verificavano che il processo di connessione avesse un UID effettivo di 0, ma non limitavano altrimenti l'accesso alla socket Unix astratta. Ciò avrebbe consentito a container dannosi in esecuzione nella stessa namespace di rete dello shim, con un UID effettivo di 0 ma privilegi 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 non appena saranno disponibili. È importante notare che i container avviati con una versione vecchia di containerd-shim devono essere fermati e riavviati, poiché i container in esecuzione continueranno a essere vulnerabili anche dopo l'aggiornamento. Se non si consente a utenti non affidabili di avviare container nella stessa namespace di rete dello shim (tipicamente la namespace di rete "host", ad esempio con docker run --net=host o hostNetwork: true in un pod Kubernetes) e si esegue con un UID effettivo di 0, non si è vulnerabili a questa problematica. Se si eseguono container con una configurazione vulnerabile, è possibile negare l'accesso a tutte le socket astratte con AppArmor aggiungendo una riga simile a deny unix addr=@**, alla propria policy. È buona norma eseguire i container con un set ridotto di privilegi, con un UID diverso da zero e con namespace isolati. I manutentori di containerd sconsigliano fortemente di condividere i namespace con l'host. Ridurre il set di meccanismi di isolamento utilizzati per un container aumenta necessariamente i privilegi di quel container, indipendentemente dal runtime di container utilizzato per eseguirlo.