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).