Alerte de sécurité OpenShift Source-To-Image (S2I)

Le service sécurité de Red Hat Product a été informé d'une vulnérabilité située dans la fonctionnalité de source à image S2I (source-to-image) fournie dans Red Hat OpenShift Container Platform 3. Un attaquant sans privilège peut utiliser cette faille pour s'approprier des privilèges et gagner accès au système hôte. Cette vulnérabilité CVE-2018-1102 a été catégorisée comme ayant un impact Critique.

Contexte

Ce problème affecte la stratégie de build de source à image. La permission d'utiliser cette stratégie est activée pour tout utilisateur ayant un rôle system-authenticated, donné par défaut à tout utilisateur qui peut s'authentifier dans OpenShift.

Ce problème a été signalé directement à Red Hat par Michael Hanselmann.

Détails de la vulnérabilité

En créant une archive tar mal formatée, un attaquant peut tirer avantage de la fonctionnalité untar de S2I au cours d'un build et booster ses privilèges, ce qui compromettra le système d'exploitation sous-jacent de l'hôte qui exécute OpenShift.

Action

Voir l'onglet Impact pour obtenir une liste des Produits Red Hat affectés et l'onglet Solution pour les informations sur la façon de résoudre le problème et les mises à jours.

Produits concernés

Red Hat Product Security a évalué l'impact de sécurité à un niveau Critique. Un attaquant peut exploiter cette vulnérabilité pour acquérir des permissions root sur un nœud OpenShift.

Les versions de produits Red Hat suivants sont concernés :

• OpenShift Container Platform 3.0-3.9
• OpenShift Online v3.x*
• OpenShift Dedicated v3.x*

*Red Hat a déjà patché les services affectés.

Diagnostiquer votre vulnérabilité

Il n'existe aucun moyen connu ou cohérent de détecter quand un agent malveillant possède un accès privilégié au système. Red Hat recommande de bonnes pratiques de sécurité et encourage ses clients à adopter une approche basée risque pour les activités de surveillance des système et des journaux en vue de détecter des évidences d'utilisation malveillante potentielle. Pour déterminer si un cluster est vulnérable, vérifiez la version du package atomic-openshift exécutant sur les Masters. Ce service contrôle le code qui détermine l'image du build de la source à l'image (S2I) en cours d'utilisation. Pour chaque version mineure d'OpenShift, les Masters exécutant ces versions ou versions supérieures ont été patchés :

• 3.9: atomic-openshift-3.9.25-1.git.0.6bc473e.el7
• 3.8: atomic-openshift-3.8.37-1.git.0.e85a326.el7
• 3.7: atomic-openshift-3.7.44-1.git.0.6b061d4.el7
• 3.6: atomic-openshift-3.6.173.0.113-1.git.0.65fb9fb.el7
• 3.5: atomic-openshift-3.5.5.31.67-1.git.0.0a8cf24.el7
• 3.4: atomic-openshift-3.4.1.44.53-1.git.0.d7eb028.el7

Pour les versions 3.1 à 3.3, il y a des étapes supplémentaires. Sur chaque nœud OpenShift, exécuter :

`$sudo docker images | grep ose-sti-builder`
registry.access.redhat.com/openshift3/ose-sti-builder       v3.3.46.38      cee523a4e55c   2 weeks ago     608 MB

Dans cet exemple, cee523a4e55c est une image non patchée. Comme ces images auront le même numéro de version que celui de la dernière version, il est important de vérifier sha256 sum.  Les images patchées et leurs checksums correspondantes sont :

• 3.3:  registry.access.redhat.com/openshift3/ose-sti-builder:v3.3.1.46.38 (b285a30ab8e0)
• 3.2:  registry.access.redhat.com/openshift3/ose-sti-builder:v3.2.1.34 (b536950df3d8)
• 3.1: registry.access.redhat.com/openshift3/ose-sti-builder:v3.1.1.11 (de9eb6fe3b01)

Si l'image non patchée peut être supprimée, alors il vaut mieux la supprimer car cela permettra d'avoir une copie fraîche (patchée) que l'on pourra charger la prochaine fois que l'on en aura besoin :

$ sudo docker rmi cee523a4e55c

Remarque : la checksum peut différer de ce qui est indiqué ci-dessus, mais la valeur à utiliser ici vient de : `sudo docker images | grep ose-sti-builder`

Cela peut échouer pour un certain nombre de raisons, y compris si l'image est déjà utilisée par un container en arrêt: “image is in use by stopped container xyz”. Dans un tel cas, nous ajoutons une seconde balise (arbitraire) à l'image pour que la balise de la version puisse être supprimée après cela sans erreur. Le résultat, à nouveau, est une copie fraîche (patchée) que l'on pourra charger la prochaine fois que l'on en aura besoin.

$ BADIMAGE=cee523a4e55c
$ BADVERS=v3.3.46.38
$ sudo docker tag $BADIMAGE    registry.access.redhat.com/openshift3/ose-sti-builder:donotuse
$ sudo docker rmi registry.access.redhat.com/openshift3/ose-sti-builder:$BADVERS