mini_guide_cve.md

Mini guide pour mitiger une CVE (WIP)

Une CVE est mise en liste blanche en l'ajoutant au fichier clair-whitelist.yml, dont on trouvera un exemple ici. Il faut spécifier le nom de la CVE, le paquet affecté et la raison de la mise en liste blanche.

Une mise en liste blanche est acceptable si :

• Clair détecte des vulnérabilités sur le paquet linux. En effet, le noyau utilisé par le conteneur est celui de l'hôte. On utilisera le motif Vulnérabilité Linux,
• Le paquet est à jour et ne peut pas être installé dans une version différente à cause de dépendances d'autres paquets,
• Le paquet ne peut pas être supprimé,
• Il n'existe pas de contre-mesure à la vulnérabilité,
• La vulnérabilité, même si elle est classée en criticité High, a peu de conséquences pour Picasoft. Cela peut être le cas pour une attaque par déni de service causant un usage de 100% du processeur, qui n'aura d'impact que sur Etherpad en raison des limitations de ressources.

Si jamais il reste un paquet contenant une vulnérabilité High, et que les conditions ci-dessus ne sont pas remplies, voici deux choses à tenter avant de le whitelister ou de décider de ne pas déployer la mise à jour.

Suppression d'un paquet inutile

On prend l'exemple de la CVE-2020-8492 (High) détectée par Clair lors d'un build de pica-db-backup-rotation (commit, log de Clair)

Comme on peut le voir sur la capture d'écran ci-dessus, Clair a détecté une nouvelle vulnérabilité avec le label High. Cette vulnérabilité concerne plusieurs versions de Python, donc un premier réflexe est de vérifier quelle est la version de Python utilisée dans l'image construite.

Pour cela, récupère la version qui a été poussée sur le registry de test et on lance un conteneur temporaire:

$ docker pull docker pull registry.picasoft.net/pica-db-backup-rotation:1.0
$ docker run --rm -it registry.picasoft.net/pica-db-backup-rotation:1.0 bash

À l'intérieur du conteneur, on vérifie les versions de Python

root@91ed958145c1:/# python --version
Python 3.8.2
root@91ed958145c1:/# python2 --version
bash: python2: command not found

Ceci semble surprenant, on n'a pas de python2 et notre python3 n'est pas vulnérable. Pas de python2... vraiment ?

root@95889d5957b6:/# apt list --installed | grep -i python

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libpython2.7-minimal/now 2.7.16-2+deb10u1 amd64 [installed,local]
libpython2.7-stdlib/now 2.7.16-2+deb10u1 amd64 [installed,local]
libpython2.7/now 2.7.16-2+deb10u1 amd64 [installed,local]

On découvre ainsi qu'il y a bien une partie de Python2 dans notre image. Mais d'où vient-elle ?

root@95889d5957b6:/# apt-cache rdepends libpython2.7
libpython2.7
Reverse Depends:
  libmailutils5
  mailutils

Et mailutils ?

root@95889d5957b6:/# apt-cache rdepends mailutils
mailutils
Reverse Depends:

Il semblerait qu'on arrive à une impasse, mais non ! On peut toujours exécuter une à une les commandes du Dockerfile pour retrouver qu'est-ce qui a installé mailutils.

On finit par trouver que c'est cette ligne:

    && apt-get -y install cron \

En effet, lorsqu'on installe cron avec la commande précédente, apt installe énormément de dépendances qui ne sont pas nécessaires pour notre cas. On peut donc utiliser l'option --no-install-recommends pour installer seulement le nécessaire et ainsi corriger la CVE.

On remarque que maintenant le nombre de vulnérabilités est passé de 73 à 60, et il n'y a plus aucune vulnérabilité en High. On remarque aussi que les CVE-2019-17455 et CVE-2019-18224 qui étaient dans la clair-whitelist.yml ne sont plus présentes.