Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Deux failles zero-day découvertes dans OS X
Affectent les versions 10.9.5 à 10.10.5

Le , par Stéphane le calme

40PARTAGES

4  4 
Deux vulnérabilités zero-day ont été découvertes sur le système d’exploitation OS X par un jeune développeur qui s’est présenté comme étant Luca Todesco. Sur GitHub, il a publié des détails d’un programme exploitant ces deux vulnérabilités pour entraîner une corruption de la mémoire dans le noyau d’OS X. Une fois la mémoire corrompue, elle peut alors être utilisée pour contourner le kernel Address Space Layout Randomization (kASLR) qui a été conçu pour protéger le système d’exploitation en empêchant à un attaquant d’avoir accès au root shell.

Ces deux vulnérabilités peuvent être exploitées via IOKitLib, une interface pour accéder aux périphériques à partir d'applications normales. Selon Todesco, si vous appelez la fonction de la bibliothèque IOServiceOpen avec un paramètre owningTask invalide, un IOUserClient va avoir un pointeur NULL pour la tâche appelante. Ce pointeur va se frayer un chemin au travers du système d'exploitation et sera utilisé pour localiser une variable dans la mémoire où un bit est défini. En contrôlant la plage de la mémoire à l'adresse zéros, un attaquant peut s’orienter où ces bits sont définis, et donc de manipuler la mémoire du noyau puis éventuellement prendre le contrôle de l'exécution des pleins privilèges au niveau du noyau. « Ce ne fut pas exactement le bug le plus difficile à trouver dans le monde », a ajouté Todesco.

D’après sa publication, la faille a apparemment été corrigée dans la version bêta d’El Capitan 10.11, mais le code de son exploit fonctionne de la version OS X 10.9.5 à la version OS X 10.10.5.

Il a expliqué avoir rapporté la faille aux ingénieurs Apple avant de divulguer publiquement le code de l’exploit sur GitHub. « J’avais l’intention de le publier dans un billet de blog abstrait. J’ai informé Apple, juste parce qu’Apple aurait tout simplement pu ne pas remarquer mon poste », a-t-il dit. « J’ai publié tpwn uniquement parce que je devais, ou bien j’aurais dû le garder pour moi jusqu'à 10.11 ».

Si Todesco a proposé une extension appelée NULLguard dont l’objectif était d’empêcher la réalisation de cet exploit, il a par la suite recommandé l’utilisation de SUIDGuard, un outil développé par le chercheur Stefan Esser qui rend les exploits au niveau du kernel difficiles à réaliser. « SUIDGuard est un pilote du noyau TrustedBSD qui implémente plusieurs mesures d'atténuation afin de protéger contre les faiblesses dans le système d'exploitation généralement mis à mal par des exploits», décrit la page du dépôt GitHub de SUIDGuard.


El Capitan, qui devrait être publié sous peu, embarque une nouvelle protection au niveau du système appelé rootless qui interdit aux utilisateurs et aux processus l'accès aux dossiers protégés par le système.

La semaine dernière, Apple a déployé un correctif pour colmater une faille sur DYLD_PRINT_TO_FILE (une variable d’environnement qui est en rapport avec l’éditeur de liens dynamiques dydl) qui entrainait une élévation de privilège dans la version 10.10 d’OS X.

Pour rappel, le mois passé, c’est le chercheur en sécurité Stefan Esser qui avait trouvé cette faille et il avait même proposé un correctif. « Normalement, pour des raisons de sécurité, l'éditeur de liens dynamique devrait rejeter toutes les variables d'environnement qui lui sont transmises en cas de fichiers restreints. Ceci est géré automatiquement lorsque de nouvelles variables d'environnement sont ajoutés à la fonction processDyldEnvironmentVariable (). Toutefois, dans le cas de DYLD_PRINT_TO_FILE le code a été ajouté directement à la fonction de _main de dyld », expliquait-il.

Esser a avancé que DYDL acceptait la nouvelle variable, même pour des binaires restreints comme les binaires root SUID. « Ceci est bien évidemment un problème, car il permet la création ou l'ouverture (pour l'écriture) d'un fichier dans le système de fichiers. Et parce que le fichier journal n’est jamais fermé par dyld et le fichier n’est pas ouvert avec une fermeture des exec, le descripteur de fichier ouvert est héritée par les processus enfant des binaires SUID. Ceci peut être facilement exploité pour une élevation de privilèges ».

SUIDGuard (dépôt GitHub)

Source : tpwn (dépôt GitHub), twitter Luca Todesco

Une erreur dans cette actualité ? Signalez-le nous !