Qu'est-ce que Stack Clash et que puis-je y faire?

27

J'ai entendu parler d'une nouvelle vulnérabilité nommée Stack Clash qui affecte apparemment plusieurs systèmes de type Unix (pas seulement Linux, mais aussi les BSD, Solaris également).

  • Qu'est ce que c'est? Comment un bug multi-OS est-il arrivé?
  • Comment protéger mes systèmes?
posée muru 20.06.2017 - 03:39
la source

2 réponses

29

Stack Clash est un exploit basé sur une technique assez ancienne. La mémoire utilisée par un processus est divisée en deux régions: la pile et le segment de mémoire . On imagine généralement que la pile croît vers le bas et que le tas croît vers le haut. Que se passe-t-il lorsque l'un ou l'autre se développe suffisamment pour se "battre" avec l'autre? Plus généralement, que se passe-t-il lorsque la pile devient suffisante pour empiéter sur des espaces mémoire indépendants? La vulnérabilité d'origine a 12 ans et les développeurs du noyau Linux l'ont corrigé temporairement en utilisant une page de garde . Cependant, les chercheurs de Qualys ont réussi à l'exploiter malgré la page de garde.

Rapports Ars Technica :

  

Les vulnérabilités de Stack Clash ont progressivement gagné en notoriété,   en 2005 avec les conclusions du chercheur en sécurité Gaël   Delalleau et cinq ans plus tard avec la version de Linux   vulnérabilité du chercheur Rafal Wojtczuk. Développeurs Linux    introduit une protection destinée à empêcher la pile   des affrontements, mais les recherches d’aujourd’hui montrent qu’il est relativement facile   pour les attaquants de contourner cette mesure.

     

L’attaque principale de preuve de concept développée par Qualys exploite une   vulnérabilité indexée comme CVE-2017-1000364. Les chercheurs de Qualys   développé des attaques qui utilisent Stack Clash pour exploiter séparément   vulnérabilités, notamment CVE-2017-1000365 et CVE-2017-1000367. Pour   exemple, lorsqu'il est combiné avec CVE-2017-1000367, une faille récemment corrigée dans   Sudo a également découvert par Qualys, les utilisateurs locaux peuvent exploiter Sudo pour obtenir   privilèges root complets sur une gamme d'OS beaucoup plus large. Qualys a jusqu'ici   été incapable de faire les exploits à distance exécuter du code. La semelle   application à distance, ils ont enquêté était le serveur de messagerie Exim, qui   coïncidence s'est avéré être inexploitable. Qualys a dit qu'il ne peut pas   exclure la possibilité que de tels exploits d'exécution de code à distance   exister. Qualys a déclaré qu’il publierait les exploits de preuve de concept à un   plus tard, une fois que les gens ont eu le temps de se protéger   vulnérabilités.

     

[...] Plus d'informations sont disponibles dans cette fiche technique détaillée   de Qualys et cette analyse technique de   grsecurity .

En citant l’article LWN sur le correctif original de 2010:

  

Parce que Linux ne sépare pas les pages de pile de processus et de tas,   La surutilisation d'une page de pile dans une page de tas adjacente est possible. Cette   signifie qu'une pile suffisamment profonde (d'un appel récursif pour   exemple) pourrait finir par utiliser de la mémoire dans le tas. Un programme qui peut   écrire sur cette page de tas (par exemple un client X) pourrait alors manipuler le   adresse de retour de l'un des appels à sauter à un endroit de son choix.   Cela signifie que le client peut amener le serveur à exécuter le code de son   choisir l'exécution de code arbitraire qui peut être exploitée pour gagner en racine   privilèges.

La description ci-dessus s'applique à divers noyaux de type Unix.

Alors que Ars Technica note une solution de contournement temporaire mentionnée dans le rapport Qualys ("définissez hard RLIMIT STACK et RLIMIT_AS de utilisateurs locaux et remote services à une valeur faible "), il convient de noter que cela ne nécessairement protéger contre cet exploit . Le seul moyen sûr de sortir est la mise à niveau. Selon l'analyse grsecurity:

  

Il devrait être clair que le noyau tente uniquement de résoudre ce problème   sera nécessairement toujours incomplète, car le véritable problème réside dans   manque de vérification de la pile. Puisque la solution réelle alternative dépend de   reconstruire toutes les zones d’utilisation, c’est probablement la seule solution possible pour   dans un avenir prévisible.

Le mieux que nous puissions faire maintenant est de mettre à jour le noyau vers une version corrigée.

L’exploitation de 2010 utilisait le serveur X, celui-ci utilisait sudo, le suivant pourrait être une multitude de programmes utilisateur qui, à un moment donné, s'exécuteraient sous des privilèges élevés.

Qualys n’a pas encore publié de code de preuve de concept pour les exploits (ils prévoient de le faire ultérieurement).

réponse donnée muru 20.06.2017 - 03:45
la source
1
  

Comment un bug multi-OS est-il arrivé?

Pour répondre spécifiquement à cette partie de votre question:

Ce problème est dû à l'utilisation d'un espace d'adressage partagé pour le tas (qui grandit) et la pile (qui augmente).

Cette conception est commune à de nombreux systèmes, ce qui explique pourquoi de nombreux systèmes sont vulnérables à la même classe de vulnérabilité.

    
réponse donnée user7761803 21.06.2017 - 14:21
la source

Lire d'autres questions sur les étiquettes