Une importante faille de sécurité a été découverte dans les systèmes de type Unix, les distributions Linux étant toutes concernées. Elle permet, si exploitée, d’élever les privilèges d’un utilisateur. Les chercheurs qui l’ont découverte n’excluent pas une possible attaque distante.
De nombreux systèmes d’exploitation basés sur Unix sont donc concernés par une vulnérabilité dans la gestion de la mémoire vive. Chaque application possède ainsi une pile, dont la taille grandit ou réduit en mémoire en fonction des besoins, au point parfois de se retrouver proche d’autres zones mémoires. La brèche permet de créer une collision avec ces dernières, un procédé qui ne devrait normalement pas être possible.
Collision et écrasement de zones de mémoire vive
La vulnérabilité a été découverte par Qualys, qui avait récemment alerté d’une autre faille dans Sudo. Dans un billet de blog publié hier soir, elle avertit que de très nombreux systèmes sont touchés, notamment les BSD (OpenBSD, NetBSD et FreeBSD), Solaris et a priori toutes les distributions Linux. La situation d’Android n’est pas encore arrêtée sur ce problème.
La société précise qu’Apple et Microsoft ont été avertis, dans le cas où la faille serait directement exploitable, ou détournée pour s’adapter aux spécificités de Windows et macOS.
La pile est, comme indiqué, un ensemble de données en mémoire dont la taille peut varier. Normalement, des protections existent depuis 2010 (stack page-guard) pour empêcher toute collision de cette pile avec les zones de mémoire adjacentes (stack overflow), contenant des informations différentes. La solution, poussée initialement par Red Hat, avait été ensuite proposée par Linus Torvalds pour intégration dans le kernel Linux.
La technique utilisée par Qualys consiste en fait à réintroduire les grandes lignes de la faille de 2010. Elle permet du coup de contourner ces protections, la rendant dangereuse. Des données de la pile peuvent alors déborder et écraser les autres, ou inversement.
Notez également que la vulnérabilité gagne en potentiel si elle est associée à d’autres failles. C’est notamment le cas de celle dans Sudo : combinées, les deux brèches permettent d'obtenir des droits root pour n’importe quel utilisateur.
D’une élévation de privilèges à une possible exploitation distante
La faille, nommée Stack Clash par les chercheurs, permet donc d’élever les privilèges d’un utilisateur local. En plus des effets inhérents à ce processus – qui permettrait alors de déclencher des opérations auxquelles l’utilisateur n’aurait normalement pas droit – Qualys avertit d’un autre danger.
Il y a en effet risque d’exploitation chez les prestataires fournissant de l’hébergement. Un utilisateur ayant la main sur un serveur peut ainsi exploiter la brèche pour créer une collision avec des processus appartenant à d’autres clients, mais stockés eux aussi dans la mémoire vive.
Par ailleurs, même si Qualys explique que ses quelques tests dans ce domaine n’ont encore rien donné, une attaque à distance reste théoriquement possible.
De nombreux éditeurs sur le pied de guerre
Exploitable dans une vaste liste de systèmes, la faille a provoqué un remue-ménage. Tous les éditeurs concernés travaillent actuellement sur des mises à jour que tous les utilisateurs doivent ou devront installer au plus vite, selon leur disponibilité.
Red Hat a réagi hier au problème, indiquant au passage que la vulnérabilité était estampillée CVE-2017-1364 pour le kernel Linux et CVE-2017-1366 pour glibc. Des patchs sont déjà disponibles, mais ils ne sont pas exempts de problèmes. Celui pour le kernel provoque ainsi un chevauchement de valeurs dans /proc/meminfo, pouvant entrainer des soucis de performances, en dépit de son efficacité. L’éditeur précise qu’une autre mise à jour pourrait arriver plus tard.
Une bonne partie des systèmes affectés disposent désormais d’un ou plusieurs patchs de sécurité. SI votre système n’en dispose pas encore, Qualys indique que la diffusion est probablement imminente. Il est chaudement recommandé de vérifier leur présence dans le gestionnaire de mises à jour, et de laisser ces dernières sur un mode automatique.
Pas de détails avant qu'une majorité de PC soit mise à jour
La société de sécurité précise en outre que les développeurs qui aimeraient réaliser un exploit basé sur cette faille devraient se pencher sur le logiciel Exim sur une distribution Debian en architecture i386. Qualys ne dit pas exactement comment procéder, mais montre simplement la voie.
Enfin, l’entreprise indique que les détails de la faille seront bien publiés, mais une fois un délai de sécurité passé, afin qu’une majorité de machines concernées soit d’abord mise à jour.
Commentaires (28)
#1
Debian est patché depuis hier. :-)
#2
Serveurs mis à jour ce matin, mais si Android est également touché bonjour les dégâts à nouveau…
#3
Serveur mis à jour également ce matin.
C’est vrai que pour Android, ça peut faire mal encore, si la faille peut être exploitée dessus.
#4
Les serveurs sont mis à jour pfiou … et dire que je voulais faire demi-journée. Maintenant à moi une tonne de rapport pour expliquer le problème.
#5
#6
Les systèmes Unix, c’est le mal.
Heureusement qu’il y a MultideskOS.
#7
Non en vrai Unix c’est le bien of course, au moins pour la partie serveur. Après en Desktop c’est un autre débat, chacun trouve midi à sa porte et c’est tant mieux
#8
J’ai cru comprendre qu’il fallait un accès physique à la machine à “rooter” ? Donc cette faille est à priori peu exploitable ? Chuis pas informaticien (juste linuxien sous Mint en plus) alors pas taper si je dis une connerie.
#9
MacOS est concerné aussi car basé sur Unix si je ne me trompe pas.
#10
#11
Pour un peu plus d’info :https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000373
En gros ça serait une fonction de trie un peu trop prévisible
#12
#13
Merci pour la précision. Ça reste une attaque difficile, voire très difficile, à mettre en oeuvre
#14
enfin une méthode de root efficace pour tous les android pré 20/06/17 !
#15
#16
Le dernier paragraphe parle d’Exim , donc elle est exploitable à distance
#17
Si j’ai bien compris…
Il ne s’agit pas de mémoire physique mais bien de mémoire virtuelle:
Ce que les chercheurs ont mis en évidence, c’est que les OS en question ne sont pas protégés contre une croissance de la pile qui la fait arriver sur une plage d’adresses (virtuelles) déjà utilisée pour autre chose. Ce peut être le tas (heap en anglais), mais éventuellement d’autres segments genre mémoire partagée ou fichier mappé. Il y a de quoi obtenir des effets étranges, même si obtenir exactement ce qu’on veut ne doit pas être si facile.
Pour ceux dont ce n’est pas le métier: les adresses retournées par l’OS sur une demande d’allocation mémoire dynamique (typiquement la fonction malloc() en C, l’opérateur new en C++, et la plupart des variables dans les langages qui gèrent eux-même la mémoire) sont dans le tas.
#18
#19
Merci de la rectification, j’avais un doute et je comprends mieux le problème.
En fait, la MMU ne protège pas bien de cela ; c’est un peu comme quand on travaillait avec de la mémoire physique dans des OS temps réel. On avait typiquement ce type de problème même si on maîtrisait mieux la consommation de la pile et qu’on la dimensionnait à peu près correctement tout en évitant les fonctions récursives et les grosses variables locales dans les fonctions.
#20
Ils disent pourtant : “can be used to remotely complete Steps 3 and 4 of the stack-clash”. Ce qui veut bien dire à distance.
#21
Nan mais faut lire en entier les gars… ils n’ont pas pu accomplir toutes les étapes nécessaires -> pas d’exploitation à distance possible.
#22
Pas vraiment puisqu’il faut modifier l’image de démarrage qui doit être signée.
Si tu fais autrement, tu sera root dans le mauvais contexte SElinux et tu pourras faire peau d’zob.
#23
Le patch kernel (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b… ) peut si je ne me trompe pas avoir des conséquences sur les programmes 32 bits utilisant un grand nombre de threads : 1Mo de mémoire virtuelle par thread, ce n’est pas forcément négligeable par rapport aux 1-3Go (ou 4 Go avec un kernel 64 bits) disponibles pour l’application.
#24
Cet article n’explique pas du tout le fonctionnement de la “faille”. Pour l’allocation mémoire, on a le tas (heap) qui contient ce qui est alloué par malloc(), et la pile pour les variables locales et les appels récursifs. Traditionnellement, le tas est alloué en bas de l’espace d’adressage virtuel, et la pile part du haut et se déroule vers le bas. Si on alloue trop sur la pile, il y a collision et le contenu de la pile va pourrir le contenu du tas.
Comme le noyau n’a pas de contrôle direct sur la taille de la pile (une allocation sur la pile, c’est une simple décrémentation de registre en espace utilisateur), la solution qui avait été proposée pour éviter cette collision était de garder une page mémoire (4Ko) non-mappée entre les deux, de façon à ce qu’un débordement de pile conduise à un segfault (c’est-à-dire que ça ne plante pas à l’allocation mais quand on tente de l’utiliser).
La “faille” de cette protection, c’est si on alloue plus que 4Ko d’un coup sur la pile, et qu’on n’accède pas aux données allouées, alors pas de segfault, et on a sauté par dessus la guard page. Ils proposent de passer la zone de protection non-mappée de 4Ko (une page) à 1Mo (taille par défaut d’une pile complète d’un thread sous Linux).
Pour que ce soit exploitable en tant que faille, il faut bien se rendre compte qu’il faut que le programme cible tourne sous un autre UID que celui qui mène l’attaque, accepte des données de l’extérieur, place ces données sur la pile sans vérifier leur taille (la base de toutes les attaques par buffer overflow), que par chance on saute par dessus la page de protection, et que la zone que l’on va écraser sur le tas nous permette de prendre contrôle du processus. L’attaque est difficile puisqu’on ne va pas pouvoir réécrire sur le code (le segment text est readonly), uniquement sur le tas, et en plus on ne sais pas trop où, puisque désormais on a par défaut la randomisation d’adresses.
Il vaut mieux être prudent et patcher, mais pour que ce soit exploitable, il faut quand même un sacré alignement de planètes.
#25
#26
pour du root temporaire, et permettre de modifier ensuite ce qu’il faut avec une méthode qui nécessite le root, c’est largement suffisant.
#27
Donc ils augmentent la taille de la “douve” de protection, point barre ?
#28
C’est un peu plus sophistiqué que ça, mais dans l’idée, oui. Il n’existe aucune fonction de bibliothèque standard qui alloue 1Mo sur la pile, et une application qui le ferait se rendrait d’elle-même vulnérable.
L’autre solution, qui ne peut pas être mise en défaut, consiste à compiler avec l’option -fstack-check. Le compilateur insère un accès à la pile tous les 4ko, de façon à être sûr de tomber sur la guard page même avec un inconscient qui fait un alloca() de 2Mo.