Glibc : des correctifs pour les systèmes d’exploitation, mais les conteneurs ?

C’est une autre façon de soulever la question de la sécurité des conteneurs. Dans un billet de blog, Gunnar Hellekson, directeur produit de RHEL et RHEV, ainsi que Josh Bressers, chef de produit sénior en charge de la sécurité chez Red Hat, interpellent : « la vulnérabilité de glibc dévoilée [la semaine dernière], conjointement par des ingénieurs de Google et de Red Hat, a attiré l’attention des médias, comme Heartbleed avant elle. […] Des correctifs sont distribués par les éditeurs de distributions Linux et par la communauté, mais il y a un problème : qui corrige les conteneurs ? »

Pour mémoire, le code de recherche de domaine au sein de glibc contient un bug susceptible de permettre à un attaquant d’implanter du code au sein de la mémoire d’un appareil affecté pour permettre son exécution à distance. Comme pour les vulnérabilités Heartbleed et Shellshock, celle de glibc n’a été mise en lumière que plusieurs années après son introduction, et pourrait déjà être exploitée par des pirates.

Gunnar Hellekson et Josh Bressers soulignent que « de nombreux acteurs du domaine des conteneurs Linux développent, et dans certains fournissent, des analyseurs de conteneurs pour aider à identifier les problèmes tels que celui posé par glibc […] mais ils ne contrôlent pas les conteneurs que leurs utilisateurs déploient, sans compter le système d’exploitation sous-jacent utilisé pour ces déploiements ».

Et force est constater qu’ils n’ont pas tort. Ainsi, la distribution Alpine Linux ne permet pas, en standard, d’exécuter des programmes utilisant glibc. Particulièrement compacte et légère, elle ne manque pas d’attrait pour la construction de conteneur, d’autant plus qu’elle se veut conçue en pensant sécurité.

Las, il suffit de fureter sur GitHub pour trouver des images Docker basées sur Alpine Linux et embarquant glibc. Ce qui, en soit, ne poserait guère problème si les projets correspondants étaient maintenus. L’une d’entre elles a été mise à jour récemment pour profiter de la version 2.22-r8 de glibc, corrigée. Mais ce n’est clairement pas le cas de toutes.

En définitive, Gunnar Helleksin et Josh Bressers soulignent là une évidence qu’il est peut-être tentant d’oublier trop vite : les conteneurs souffrent par essence des mêmes faiblesses que tout projet s’appuyant sur la réutilisation de composants, en notamment open source.

Fin 2013, Sonatype avait, dans une étude, souligné à quel point les logiciels modernes utilisent du code libre recyclé, contenant souvent des failles de sécurité connues. Il a fait du sujet la raison d’être de son offre Nexus d’automatisation de la chaîne logistique logicielle, dans une perspective tant de sécurité que de qualité ou encore de respect des licences. L’éditeur vient de lever 30 M$. La version 3 « milestone 5 » de sa solution Nexus, présentée en septembre dernier, fait d’ailleurs la part belle à Docker.

De son côté, Twistlock propose une solution permettant de contrôler l’accès aux conteneurs Docker, de détecter d’éventuelles anomalies, et d’assurer l’absence de vulnérabilités connues. Cette jeune pousse a justement noué, en novembre dernier, un partenariat stratégique avec Sonatype.