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).
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.
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.
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).
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é.
Lire d'autres questions sur les étiquettes security