Nouvelles fonctionnalités sécurité sur Mac OS X 10.5
Date : 04 Septembre 2008
Introduction
Bien que la version 10.5 de Mac OS X (également appelée Leopard) soit sortie depuis presqu’un an il nous semble important d'en parler aujourd'hui parce que :
- cette dernière version représente une évolution majeure pour le système Mac OS X en termes de sécurité
- certaines des fonctions de sécurité introduites sont de plus des fonctionnalités inédites si l’on considère l’ensemble des systèmes d’exploitation existants sur le marché.
Le présent article s’attachera donc à décrire quelques fonctionnalités clés introduites dans Mac OS X Leopard.
« Library randomization » et « NX bit » ou comment se protéger des "buffer overflows"
Cette fonctionnalité est probablement l’une des plus importantes apportées par Mac OS X 10.5. Bien que complètement transparente pour l’utilisateur, la fonctionnalité appelée « library randomization » introduit un aléa dans les adresses utilisées lors du chargement de bibliothèques dynamiques en mémoire.
En effet, l’une des vulnérabilités logicielles les plus courantes est ce que l’on appelle le débordement de mémoire (« buffer overflow » en anglais). Dans ce scénario, un attaquant fournit à une application vulnérable des arguments ou paramètres trop longs qui dépassent donc la taille mémoire qui est normalement allouée pour les stocker, ce qui peut par exemple écraser l’adresse de retour d’une fonction et ainsi permettre de modifier le cours de l’exécution d’un programme. Le « shellcode », qui est le code que l’attaquant souhaite faire exécuter à la victime à son insu, peut entre autres contenir des appels à des fonctions système sous la forme d’adresse en mémoire. Sur beaucoup de systèmes d’exploitation, ces adresses sont prévisibles et facilitent ainsi l’exécution de code arbitraire à distance. Sous Mac OS X Leopard, ces adresses sont désormais différentes à chaque démarrage du système ce qui rend quasiment impossible l’exploitation de ces failles de sécurité car l’attaquant a à deviner l’adresse des fonctions en mémoire parmi des milliers de possibilités.
Nota : cette fonctionnalité est aussi souvent appelée ASLR (Address Space Layout Randomization) et a notamment été introduite sous ce nom dans les environnements Microsoft à partir de Windows Vista et Windows Server 2008. Pour plus d’information à ce sujet, vous pouvez lire ce très bon article Wikipedia (en anglais).
Toujours dans le domaine de la protection lors de l’exécution, Mac OS X 10.5 prend désormais en charge la désactivation d’exécution de code (fonction appelée « NoExecute », « ExecuteDisable » ou encore « NX bit ») sur certaines zones mémoire, et ce sur toutes les architectures supportées. Cela permet notamment au système d’interdire au processeur d’exécuter du code dans de la mémoire normalement réservée par l’application pour contenir des données (pile, tas etc.)
Marquage des applications et fonctionnalité de quarantaine (application tagging)
Les applications qui téléchargent des fichiers depuis Internet ou qui reçoivent des fichiers depuis des sources non sûres (pièces jointes à des e-mails par exemple) peuvent utiliser une fonctionnalité dite de quarantaine pour fournir une première défense contre les logiciels malveillants comme les chevaux de Troie. Quand une application reçoit un fichier inconnu, elle ajoute automatiquement à celui-ci des métadonnées (attributs de quarantaine). Ainsi, les fichiers téléchargés avec Safari, Mail ou iChat sont « tagués » avec des métadonnées indiquant qu’il s’agit de fichiers téléchargés et précisant l’URL source, la date et l’heure du téléchargement. Le point intéressant est que ces métadonnées sont propagées lorsqu’on décompresse une archive .zip ou .dmg de sorte qu’un fichier extrait à partir d’une archive ZIP téléchargée contiendra lui aussi le tag indiquant qu’il s’agit d’un fichier téléchargé.
Ces métadonnées sont par la suite utilisées par l’inspecteur de téléchargements (download inspector) pour éviter l’ouverture accidentelle de fichiers potentiellement dangereux. La première fois qu’un utilisateur tente d’exécuter une application téléchargée, l’inspecteur de téléchargements examine le fichier et si des métadonnées sont présentes, il demande à l’utilisateur la permission d’exécuter ou d'ouvrir le fichier en affichant les informations relatives au téléchargement (typiquement l’URL de provenance). Si l’utilisateur reconnaît les informations et décide de faire confiance au fichier, cette confirmation ne lui sera plus demandée et les attributs de quarantaine seront retirés du fichier.
Cette nouvelle fonctionnalité permet de réduire le nombre d’avertissements affichés par le système lors de l’exécution d’une application potentiellement non sûre. De plus, les informations montrées à l’utilisateur sont maintenant beaucoup plus utiles et pertinentes.
Signature d’application
Mac OS X 10.5 offre la possibilité à tout développeur de logiciel de signer ses applications. Le système utilise cette signature pour vérifier à la fois l’identité de l’application (qu’il ne s’agisse pas d’un faux programme) ainsi que l’intégrité (non-modification) de celle-ci. Toutes les applications distribuées avec le système Mac OS X sont désormais signées par Apple. La signature d’application ne constitue certes pas une protection à proprement parler, mais sa pleine intégration à des fonctionnalités clé du système permet d’augmenter significativement le niveau de sécurité global de la machine.
A titre d’exemple, des fonctionnalités comme le contrôle parental, le gestionnaire de mots de passe (Keychain) ou le pare-feu utilisent les signatures pour vérifier que les applications avec lesquelles elles interagissent sont bien des versions non modifiées fournies par l’éditeur. Dans le cas du pare-feu, la signature est utilisée pour authentifier et vérifier l’intégrité des applications pour lesquelles on a autorisé l’accès au réseau. Si l’application n’a pas été signée au départ par l’éditeur, c’est le système qui se charge d’ajouter cette signature pour permettre notamment au pare-feu d’identifier ce programme et de vérifier qu’il ne sera pas modifié par la suite.
La signature d’application peut être également utilisée pour vérifier que le processus de remplacement d’un programme par un autre programme constitue bien une mise à jour, le système propageant lui-même les privilèges accordés pour cette application de la version initiale à sa nouvelle version.
Pour l’utilisateur final, cette fonctionnalité apporte un meilleur confort d’utilisation (moins de demandes de confirmation systématiques) et de plus une protection efficace contre les tentatives de modifications d’exécutables (comportement classique des vers ou virus).
Contrôles d’accès obligatoires (Mandatory Access Control)
Mac OS X implémente désormais le modèle de « contrôle d’accès obligatoire (« Mandatory Access Control » en anglais, que l’on abrège généralement par l’acronyme MAC). Les politiques de sécurité MAC sont par définition des politiques qui ne peuvent pas être redéfinies par l’utilisateur. Plus précisément, on parlera de contrôle d’accès obligatoire lorsque la politique de sécurité du système d’information impose que les décisions de protection ne soient pas prises par le propriétaire des objets (fichiers, processus …) concernés, et lorsque ces décisions de protection sont imposées par le système lui-même.
Cette politique s’oppose en ce sens aux politiques de sécurité discrétionnaires (Discretionary Access Control – DAC) qui au contraire considèrent que le propriétaire d’un objet est responsable de cet objet et peut lui attribuer les droits d’accès qu’il souhaite (l’exemple typique étant l’attribution des droits classiques sous UNIX).
Sous Mac OS X donc, des restrictions de sécurité sont définies ou peuvent être définies au niveau du noyau du système d’exploitation et ne peuvent par conséquent pas être redéfinies. La plupart de ces politiques de sécurité sont invisibles pour l’utilisateur final, mais elles constituent en fait les technologies sous-jacentes de plusieurs nouvelles fonctionnalités comme le « sandboxing » d’applications, le contrôle parental ou encore la sécurisation de l’application de sauvegarde du système « Time Machine ».
La « Time Machine » illustre particulièrement bien la différence entre le contrôle d’accès obligatoire et le modèle classique des privilèges utilisateurs en n’autorisant la modification ou la suppression de fichiers sauvegardés qu’à partir de cette application. En ligne de commande, même un utilisateur connecté en tant que "root" ne pourra pas altérer les sauvegardes, ce qui permet non seulement d’éviter toute corruption involontaire de celles-ci mais qui permet également qu’un programme malveillant ne puisse pas non plus les modifier.
La politique de contrôle d’accès est aussi implémentée au niveau du service d’exécution des processus du système pour pouvoir empêcher l’exécution d’applications non autorisées (cas du contrôle parental).
Dans le cas de la fonctionnalité de « sandboxing » qui est détaillée plus bas, le contrôle d’accès obligatoire permet de restreindre l’accès aux ressources système selon un profil bien déterminé : autrement dit, même un processus s’exécutant en tant que "root" peut n’avoir en réalité que très peu de privilèges.
Bac à sable ou "Sandboxing"
La fonctionnalité de « sandboxing » permet de s’assurer que les programmes une fois lancés ne font que les actions qu’ils sont sensés faire. Pour cela, on peut définir un profil pour chaque application en :
· décrivant des restrictions sur les fichiers auxquels elle peut accéder,
· définissant si elle peut accéder au réseau
· ou même si elle peut exécuter d’autres applications.
On pourra parler ici de politique de sécurité basée sur les rôles (Role-Based Access Control – RBAC) : une application a un rôle précis et les permissions qui lui sont accordées doivent correspondre précisément à ce rôle. Pour cela, la fonctionnalité de « sandboxing » se base sur les politiques de sécurité d’accès obligatoires que nous avons décrites dans le paragraphe précédent, des politiques qui sont implémentées dans le noyau du système d’exploitation. Des profils peuvent donc être développés pour chaque application sensée s’exécuter dans un environnement restreint. Ils décrivent essentiellement l’ensemble des ressources accessibles ou non accessibles pour l’application concernée.
Par défaut sous Mac OS X 10.5, des profils sont déjà définis pour des applications ou services dont le rôle principal est d’assurer la connectivité réseau du système. Par exemple des services tels que MDNSResponder (service apportant le support de
D’autre part, un service comme « quick look » (permettant la visualisation d’un fichier sans l’ouvrir) ou le démon « SpotLight » (service d’indexation des fichiers de Mac OS X) qui reçoivent régulièrement en entrée des fichiers potentiellement non sûrs, sont restreints par un profil « sandbox » pour empêcher la compromission du système par des fichiers au contenu actif.
Pare-feu applicatif
Un nouveau pare-feu applicatif a fait son apparition dans Mac OS X 10.5 et permet en particulier à des utilisateurs novices en matière de sécurité de bénéficier d’une protection relativement efficace. Ce nouveau pare-feu permet de bloquer ou d’autoriser des connexions entrantes ou sortantes non plus sur la base de ports (TCP/UDP), comme cela est le cas dans la plupart des systèmes d’exploitation de type UNIX, mais d’attribuer ces règles par application.
Les utilisateurs peuvent par exemple restreindre l’accès aux seuls services réseau indispensables (tels que ceux requis pour utiliser DHCP, BOOTP, les VPNs IPSec ou encore la connectivité "Bonjour"), mais ils peuvent aussi réaliser ce filtrage par application de manière individuelle. Comme nous l’avons déjà mentionné, le pare-feu applicatif utilise la signature d’applications pour authentifier les applications lorsqu’elles demandent une connexion au réseau, les applications non signées à la base étant automatiquement signées la première fois qu’elles sont ajoutées aux règles du pare-feu pour les identifier de manière unique.
Pour les utilisateurs plus expérimentés, le pare-feu IPFW est bien sûr toujours disponible sur le système. IPFW traite les paquets au niveau de la couche protocole de la pile réseau (couches 3 et 4 du modèle OSI) tandis que le pare-feu applicatif comme son nom l’indique filtre le trafic au niveau de la couche applicative, par conséquent les règles enregistrées dans IPFW restent toujours prioritaires.
Compte "invité" sécurisé
La fonctionnalité « compte invité » permet à n’importe qui de se connecter au système sans posséder de mot de passe. Cette fonctionnalité peut bien évidemment être activée ou désactivée à loisir pour donner facilement un accès temporaire au système. La particularité de ce compte par rapport à un compte utilisateur non privilégié classique est que toutes les données qui y sont associées sont détruites à la déconnexion du dit invité : ces données incluent entre autres les paramètres de personnalisation du bureau, les messages électroniques, l’historique et les cookies de navigation Web etc.
Cette approche présente plusieurs avantages notables :
- Le compte est en tout point semblable à un compte Mac OS X classique, autrement dit toutes les contraintes de sécurité (contrôle parental, « sandboxing » etc.) peuvent également lui être appliquées. Ce compte ne permet par conséquent pas à un utilisateur potentiellement malveillant de compromettre la machine hôte. Le contrôle parental peut en particulier être utilisé pour ne pas autoriser le lancement de certaines applications.
- Le compte étant détruit à la déconnexion, aucun fichier potentiellement malveillant ne peut subsister sur le système. La destruction du compte permet également à l’utilisateur invité de ne pas révéler par mégarde des données potentiellement confidentielles lui appartenant.
- Enfin, ce compte possédant un identifiant unique ne variant pas d’une connexion à l’autre, un seul compte invité peut être utilisé à la fois.
Il semble cependant, d’après l’article intitulé « A Roundup Of Leopard Security Features, publié sur Matasano.com que l’utilisateur invité puisse dans certains cas réaliser des actions permettant de maintenir en quelque sorte sa présence après sa déconnexion. Ces actions incluent notamment la possibilité de créer des tâches planifiées (cron jobs) ou de monter des systèmes de fichiers distants. Il est certain que l’idée du compte « invité » est réellement intéressante et qu’elle pourrait constituer une fonctionnalité unique du système Mac OS X si elle était pleinement opérationnelle. Cependant, dans l’état actuel des choses, elle n’apporte pas réellement la sécurité escomptée.
Conclusion
Mac OS X introduit par ailleurs un grand nombre d’autres fonctionnalités de sécurité comme la gestion de multiples certificats pour un même utilisateur, le contrôle parental, la solution de sauvegarde (backup) du système Time Machine, la possibilité d’utiliser des clés de chiffrement plus robustes pour crypter le contenu d’un disque dur ou bien la présence d’un client VPN universel offrant une meilleure compatibilité avec les solutions VPN existantes sur le marché. Il ne nous a pas été possible dans le cadre de cet article de détailler toutes les améliorations apportées par Mac OS X Leopard, mais nous pouvons dire, au vu de ce que nous venons de présenter, que cette nouvelle mouture du système d’exploitation d’Apple représente l’évolution la plus significative de toute l’histoire de ce système en terme de sécurité. Certaines évolutions (comme l’intégration d’une solution de sauvegarde permettant de visualiser le système tel qu’il était à un instant "t") sont mêmes complètement nouvelles et spécifiques au système d’Apple.
On pourra cependant regretter que certaines fonctionnalités n’aient pas été pleinement ou correctement implémentées, si l’on se réfère à l'article (précédemment cité) publié par Thomas Ptacek sur Matasano.com. Par exemple la fonctionnalité de « sandboxing » ne profite apparemment pas aux applications les plus critiques telles que le navigateur Web Safari ou le client Mail de Mac OS X. La fonctionnalité « Library Randomization » semble quant à elle n’avoir été implémentée que de manière partielle (toutes les bibliothèques dynamiques n’en bénéficient pas). Enfin, Apple semble dire dans sa documentation que toutes ses applications sont signées numériquement, mais cela ne semble pas être le cas dans la pratique.
Nous pouvons cependant espérer que ces différents problèmes soient corrigés progressivement avec les prochaines mises à jour de sécurité du système d’exploitation.
Pour plus d’information
- Leopard security configuration (Apple)
- Address space layout randomization (Wikipedia)
- A Roundup Of Leopard Security Features (Matasano.com)
