Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

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

Public Date:
Updated -
Status
Ongoing
Impact
Critical

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

  

On conseille fortement aux clients Red Hat avec des versions affectées de l'image ose-sti-builder dans leurs registres OpenShift de les mettre à jour dès qu'une nouvelle image sera disponible si la désactivation des builds source-à-image (S2I) n'est pas une option. Le processus normal de mise à niveau est utilisé pour les versions 3.4 à 3.9. Cela implique de s'assurer que le paquet atomic-openshift-utils est à jour et d'exécuter les playbooks de mise à jour :

Pour les clusters exécutant sur des versions 3.1 à 3.3, les admins doivent extraire l'image patchée pour la diriger vers tous les nœuds du cluster. Si les étapes de «Diagnostique» vous mènent à conclure que vous utilisez une version vulnérable, vous pouvez mettre à jour manuellement l'image en procédant comme suit :

  1. Établir une connexion SSH vers chaque hôte de nœud
  2. Exécuter `docker pull registry.access.redhat.com/openshift3/ose-sti-builder`
  3. Vérifier que l'image extraite correspond à la checksum utilisée dans la section «Diagnostique» pour la version de cluster.

Remarque : ces images peuvent être balisées à n'importe quel numéro de version au sein d'un même niveau de correctif mineur. Par exemple, v3.3.1.36.38 peut être balisé v3.3.1.46.11 si cela correspond à la version du cluster installé.


Mitigation

Red Hat recommande à ses clients de mettre à jour leur logiciel dès que les correctifs sont disponibles.

Les clients peuvent désactiver la stratégie de build S2I (source-to-image) pour empêcher l'accès à la fonction exploitable. Vous trouverez des informations sur la façon de désactiver la stratégie de build de source à image dans la documentation produit.

On conseille à nos clients de prendre une approche basée risque pour résoudre ce problème. Les systèmes qui exigent des niveaux de sécurité et de confiance élevés doivent être réglés en premier, et doivent être isolés des systèmes suspects tant que la durée de traitement nécessaire n'a pas été encore appliquée à ces systèmes pour en réduire le risque d'exploitation.


Mises à jour pour les produits concernés

ProduitAlerte / Mise à jour
OpenShift Container Platform 3.9RHSA-2018:1227
OpenShift Container Platform 3.8RHSA-2018:1229
OpenShift Container Platform 3.7RHSA-2018:1231
OpenShift Container Platform 3.6RHSA-2018:1233
OpenShift Container Platform 3.5RHSA-2018:1235
OpenShift Container Platform 3.4RHSA-2018:1237
OpenShift Container Platform 3.3RHSA-2018:1239
OpenShift Container Platform 3.2RHSA-2018:1241
OpenShift Container Platform 3.1
RHSA-2018:1243
OpenShift Container Platform 3.0Voir Mitigation ci-dessus ou Contactez le support clients.

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In