diff --git a/README.md b/README.md index f812906b8e1c93e77b3153c799e6aa0f850f6edd..4aa37d9509a18aafd42afcfe38af9f7784c971da 100644 --- a/README.md +++ b/README.md @@ -127,7 +127,9 @@ L'erreur peut aussi venir d'un nom d'image mal formaté dans le Docker Compose ( Cette analyse échoue lorsque des CVE avec une criticité `High` ou plus sont détectées. Les CVE de niveau plus faible étant inévitables, la CI n'échoue pas et se contente de les afficher. -Clair vous indique quels paquets sont vulnérables. Plusieurs choix s'offrent à vous : mettre la CVE en liste blanche ou mitiger la CVE. +Clair vous indique quels paquets sont vulnérables. Plusieurs choix s'offrent à vous : mitiger la CVE (choix à privilégier) ou mettre la CVE en liste blanche. + +[Mini guide pour mitiger une CVE !](/doc/mini_guide_cve.md) Une CVE est mise en liste blanche en l'ajoutant au fichier `clair-whitelist.yml`, dont on trouvera un exemple [ici](./pica-mattermost/clair-whitelist.yml). Il faut spécifier le nom de la CVE, le paquet affecté et la raison de la mise en liste blanche. @@ -138,8 +140,6 @@ Une mise en liste blanche est **acceptable** si : * 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. -Sinon, on règlera la CVE en prenant les mesures nécessaires. - Ensuite, on pousse les modifications et la CI ré-effectuera les tests de vulnérabilités, en reconstruisant l'image si nécessaire. #### Lors de l'analyse de sécurité dynamique diff --git a/doc/images/clair_log_1.png b/doc/images/clair_log_1.png new file mode 100644 index 0000000000000000000000000000000000000000..122ba761aeff7f593dfd1abe230817eea2170801 Binary files /dev/null and b/doc/images/clair_log_1.png differ diff --git a/doc/images/clair_log_2.png b/doc/images/clair_log_2.png new file mode 100644 index 0000000000000000000000000000000000000000..9cd2ca831173472dbcdb8771ddc18b65a7e6b0df Binary files /dev/null and b/doc/images/clair_log_2.png differ diff --git a/doc/mini_guide_cve.md b/doc/mini_guide_cve.md new file mode 100644 index 0000000000000000000000000000000000000000..f905a8f18cd8a199d82a52c32143177e6c57a393 --- /dev/null +++ b/doc/mini_guide_cve.md @@ -0,0 +1,68 @@ +# Mini guide pour mitiger une CVE (WIP) + +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](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/commit/078d448a53da4be9330fd0ac9304a7eb3a26e969), [log de Clair](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/jobs/883005)) + + + +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](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/078d448a53da4be9330fd0ac9304a7eb3a26e969/pica-db-backup-rotation/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](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/commit/5b6bd31225581c40738e9a131a59dec4c8417848). + + + +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.