. Sécurité sous Windows 2000 / 2003 / XP.......... 1
Historique des versions Version Date Modifications 1.0 Mai 2004 Création du document 1.1 Décembre 2004 Refonte globale et changement de mise en forme 1.2 Février/Mars 2005 Corrections mineures 3
Table des matières! "! #! $ %%! &! '! %! % " # ' $ " % "!! " " ( "" "" 5
" % " "$ % #! %% # )*+ ## ' #! # #, $ $ %-%. $ %-%. $ $ / $ 0 $ 0 $ 0!% % " %% " %1! $ %'( %'1 -. %' # -. 0 %!!! " /2 % %' " # % -. $%!"!! "# 6
# " &&&&' (! " * " "" 0 # " # 7
34567894:63 Historique Le système Windows NT a été développé depuis 1989 par Microsoft. Initialement prévu pour fonctionner avec un processeur Risc i860 (le N-Ten, c est d ailleurs de là que provient l acronyme NT) et pour être compatible avec OS/2, rapidement le système s orienta vers les processeurs Intel x86 et vers une compatibilité avec Windows. La première démonstration de NT eut lieu au Comdex en octobre 1991, puis la première version bêta vit le jour au printemps 1992 avant le lancement de Windows NT 3.1 en juillet 1993. La suite Office fut disponible en août 1994, immédiatement suivie d une évolution majeure de NT qui devint NT 3.5. L étape suivante fut la sortie de Windows NT 3.51 en mai 1995 qui offrait la compatibilité avec Windows 3.11 et en reprenait l interface graphique. La version actuelle, Windows NT 4.0, sortie en août 1996, reprenait l'interface graphique de Windows 95. Enfin, la première version bêta de Windows NT 5.0 fut adressée aux développeurs en septembre 1997. En 1999, Microsoft annonçait la disparition de Windows NT 5.0 au profit de Windows 2000, censé fusionner les développements conjoints de Windows 98 et de Windows NT. Windows 2000 est actuellement commercialisé par Microsoft depuis le 17 février 2000. Parallèlement à cette sortie tant attendue de son nouveau système d exploitation, Microsoft poursuivait l'évolution de son offre avec le développement de Windows 2003 ex Windows.NET -, remplaçant annoncé de Windows 2000 Serveur. Avec cette nouvelle mouture du système d exploitation de la firme de Redmond, et exclusivement dédiée aux serveur, le système Windows XP, évolution naturelle de Windows 2000 Professionnel, s intègre tout naturellement dans un rôle de poste client. Windows 2000 L apparition de Windows 2000 constitue une véritable révolution dans le processus de développement des systèmes d exploitation chez Microsoft. Les similitudes entre Windows NT 4.0 et Windows 2000 sont grandes, et ce parce que la technologie sousjacente reste identique, mais le système Windows 2000 demeure bien plus qu une version améliorée de Windows NT 4.0. Si le système Windows NT 4.0 concevait la gestion des ressources qui lui étaient confiées comme une structure «à plat» utilisant des protocoles de gestion et de communication 9
propriétaires ou adaptés de développements antérieurs 1, le système Windows 2000 intègre dès sa conception une notion de forte hiérarchisation de ses composants et, surtout, une volonté d ouverture sur le monde de par l adoption de nombreux protocoles standardisés (Kerberos V5, IPSec, LDAP, SSL/TLS, X509 ). La plus importante (r)évolution de Windows 2000 demeure la notion d Active Directory : cette nouveauté majeure constitue la pierre angulaire de tout l édifice Windows 2000. Windows 2003 Longtemps attendue, et maintes fois repoussée, la sortie officielle de Windows 2003 sonne le glas de Windows NT 4.0 Serveur. Si la coexistence pacifique entre Windows NT et Windows 2000 était encore possible, la conception et les choix de paramétrage par défaut de Windows 2003 sont désormais ouvertement hostiles à Windows NT 4.0 Anciennement présenté sous le nom «Windows.NET» auprès du public, Windows 2003 entérine définitivement les choix réalisés pour Windows 2000 et poursuit sa logique de développement. Curieusement, cette nouvelle version du système ne constitue pas une réelle évolution majeure ; Windows 2003 reprend les mêmes bases que Windows 2000 et en améliore / complète / corrige certains concepts. A vrai dire, seule la notion de «framework.net» permet à Windows 2003 de s affirmer comme un nouveau système et non comme une simple évolution de Windows 2000 Serveur et qui en corrige ses bugs résiduels. 1 Le système Windows NT conserve de nombreuses traces de ses prédécesseurs. Ainsi le système de gestion de fichier NTFS doit-il beaucoup au système HPFS développé à l origine pour le système OS/2 d IBM. 10
59;:4<9485<78=>=4?@<! " " #$ % " Préambule Les systèmes d'exploitation sont généralement constitués de parties qui prennent en charge chacune un certain nombre de fonctionnalités, les parties les plus complexes s'appuyant toutes sur les services plus fondamentaux. Ainsi, la gestion de la mémoire et des threads d'exécution, et parfois même les systèmes de fichiers, se trouvent naturellement dans les fonctionnalités de base de tous les systèmes. Au dessus de ces fonctions de base, organisées comme des couches successives de fonctionnalités, on retrouve toutes les fonctions haut niveau du système. On place généralement dans cette catégorie la gestion du réseau, la gestion des périphériques d'entrée / sortie (clavier, écran, ports de communication). Vient ensuite la couche utilisateur, qui prend en charge l'interface du système avec ses utilisateurs. Cette couche est en général très simplifiée, et fonctionne souvent dans le mode ligne de commande. Ceci signifie que les commandes du système sont saisies au clavier et les résultats sont renvoyés à la suite de leur exécution. L'interface graphique se place encore au dessus de la couche utilisateur. Celle-ci prend en charge la gestion de toutes les ressources graphiques, mais ne va en général pas plus loin. La gestion des fenêtres par exemple est effectuée par une couche supplémentaire, sur laquelle s'appuient les applications. 11
Bien que les fonctionnalités des systèmes d'exploitation soient structurées en couches logicielles, la plupart des systèmes sont relativement rigides, du fait d'un grand nombre d'interactions entre les différentes parties du système. Cette rigidité est la source de la grande difficulté que les développeurs éprouvent pour faire évoluer et maintenir les systèmes d'exploitation. C'est aussi le facteur d'instabilité numéro un : le dysfonctionnement d'un service isolé peut engendrer la mort du système complet. Cette architecture, qui est très courante malgré ces défauts, se dit «monolithique». On trouve dans cette catégorie de système certains systèmes courants, tels que Windows 95/98, et les systèmes Unix (dont GNU/Linux). À l'opposé, on retrouve l'architecture dite des «micronoyaux». Dans ce modèle de développement, seul les services de base sont exécutés avec des privilèges systèmes. Tous les autres services sont considérés comme des extensions du micronoyau, et sont de ce fait relativement indépendants les uns des autres. Ce type d architecture suppose de mettre en place un mécanisme de communication efficace entre les différents modules du système. Ces mécanismes de communication interprocessus ultra performants sont fournis par le micronoyau. Cette approche micronoyau apporte, du moins en théorie, un grand nombre d avantages dont le premier d entre eux demeure la portabilité du système. En effet, dans la mesure où c est le micronoyau qui contient les parties les plus spécifiques à la plate-forme matérielle, les couches logicielles supérieures ont alors la possibilité d utiliser un niveau d abstraction tel qu elles deviennent moins sujettes à des problèmes de compatibilité. Porter sur une autre architecture matérielle un système utilisant une approche micronoyau devient alors plus facile, puisque seul un noyau réduit doit alors être adapté pour se conformer aux nouvelles spécificités matérielles. D ailleurs, c est là la principale raison historique pour laquelle les chercheurs se sont intéressés à cette technique. Le second intérêt d une telle approche réside dans la sécurité et surtout la stabilité du système. Si seule une portion réduite de code (le micronoyau) est exécutée avec des privilèges systèmes, le système d exploitation gagne nécessairement en stabilité. En effet, quand un processus s exécutant avec des privilèges systèmes plante, la probabilité pour que tout le système soit affecté par cette erreur d exécution est grande. A l inverse, un processus avec peu de privilèges peut difficilement gêner tout le système, d une part parce son jeu d instruction réduit lui interdit un certain nombre d opérations critiques et d autre part parce qu il s exécute sous le contrôle du noyau. Dès les premiers développements de Windows NT, Microsoft s était engagé dans la voie du micronoyau en s inspirant largement de l architecture du vénérable système MACH et Windows 2000 conserve les traces de ce type d approche même si celle-ci a due être largement adaptée comme on le verra plus loin. Le seigneur des anneaux Sur les processeurs modernes, les processus ont la possibilité de s exécuter selon des modes d utilisation différents. Les différences entre ces modes portent essentiellement sur le jeu d instruction disponible. Ainsi, les processeurs Intel de génération x86 (depuis le 80386) supportent jusqu à 4 niveaux d exécution, appelés «rings» et numérotés de 0 à 3. En «ring 0», un processus dispose de l intégralité du jeu d instruction du processeur. Il peut adresser directement certains registres et surtout la mémoire physique du système. En «ring 3», un processus ne peut directement adresser la mémoire physique et, surtout, il ne peut plus directement revenir en «ring 0». 12
Ainsi, plus le niveau de «ring» augmente, moins le processus dispose d instructions, ce qui définit les niveaux d exécution comme des niveaux de privilèges. Sous Windows 2000, le système autorise l exécution des processus selon deux modes distincts : le mode Utilisateur (User Mode) et le mode Noyau (Kernel Mode), correspondant respectivement aux rings 0 et 3 des architectures Intel. Pourquoi Microsoft n a t-il alors pas utilisé au maximum les possibilités du processeur Intel et s est-il limité aux seuls Rings 0 et 3? Parce que le système Windows NT, père direct de Windows 2000, a toujours été conçu pour être porté sur de nombreuses platesformes matérielles dont des systèmes à processeur RISC. Or, l immense majorité des processeurs RISC ne dispose que de 2 niveaux d exécution et non de 4 comme les systèmes Intel x86. Dans un souci de portabilité, mais également de simplicité, le choix a donc été fait de se limiter à deux niveaux d exécution distincts. Toute la sécurité du système Windows 2000 repose alors sur ces deux modes d exécution. Le système tourne en Kernel Mode et fournit alors des services aux processus en User Mode. Un processus en User Mode ne peut passer en Kernel Mode puisque les instructions nécessaires à ce passage lui sont interdites (mieux : elles n existent pas!). Ne pouvant accéder aux ressources matérielles et à la mémoire physique, ces processus sont donc obligés de passer par un service du système, fonctionnant lui en Kernel Mode et généralement appelé «service dispatcher». Architecture globale Le noyau de Windows 2000 est architecturé suivant le schéma présenté ci-dessous : 13
Au dessus d une couche d abstraction matérielle, créée à l origine pour simplifier le portage du système, on trouve les pilotes de périphériques, le noyau et l ensemble des gestionnaires du système, organisés par modules distincts. On peut cependant simplifier cette architecture de la façon suivante : Un des modules fondamentaux de l exécutif est le gestionnaire d objet. En effet, le concept de base utilisé dans Windows 2000 est l objet. Il n existe pas moins de 27 types d objet gérés par le système, parmi lesquels : les événements (événement système, interruption ), les fichiers (fichier réel sur disque ou fichier virtuel correspondant à un périphérique), jeton d accès (identification d un utilisateur), port LPC (utilisé pour la communication inter processus), processus, sémaphore, thread, timer. Le système d exploitation a la charge de créer et détruire ces objets et, pour ce qui nous intéresse, de gérer des «Security Descriptor» pour chacun d entre eux : ceux-ci indiquent qui a le droit de faire quoi sur ces objets. Communication avec le noyau Le cœur du système Windows 2000 réside dans le fichier NTOSKRNL.EXE. Ce seul fichier contient à la fois le noyau et l exécutif du système. Les fonctions systèmes disponibles dans le mode utilisateur sont quant à elles exportées par la NTDLL.DLL et les autres sous-systèmes d environnement. 14
Notons qu il existe 4 versions distinctes de ce noyau : NTOSKRNL.EXE Version Monoprocesseur. NTKRNLMP Version Multiprocesseur. NTKRNLPA Version Monoprocesseur avec PAE 1. NTKRPAMP Version Multiprocesseur avec PAE. Lorsque l on souhaite faire appel à une fonction du noyau (écrire dans un fichier par exemple), il suffit donc d appeler la fonction interne correspondante. La liste des fonctions disponibles du noyau se nomme la «Native API». On peut reconnaître le composant touché par chaque fonction de la Native API par le préfixe du nom de la fonction. Préfixe Cc Ex Exp FsRtl Hal Io Ke Ki Lsa Mm Ob Po Ps Ps Rtl Se Wmi Zw Composant Cache Manager Routines de support de l exécutif Routines privées de support de l exécutif (non exportées) File System Run-Time Library Hardware Abstraction Layer (couche d abstraction matérielle) Sous-système d Entrées/Sorties Kernel (Noyau) Kernel Internal (non disponible en dehors du noyau) Sous-systèmes d authentification Gestionnaire de mémoire Object Manager Power Management Support des processus Process Structure Run-Time Library Sécurité Windows Management Instrumentation Accès aux fichiers et au registre 1 Physical Address Extension 15
La dernière fonction appelée en mode utilisateur par ces «fonction natives» est alors la fonction «Change Mode to Kernel». Cet appel génère une interruption logicielle (l interruption 2E sur les machines x86) qui est traitée par le «service dispatcher» en mode noyau. A l issue du traitement, le système retourne au User Mode et rend la main. Dans les faits, aucun programme n est censé accéder directement à cette Native API pour la bonne et simple raison que Microsoft ne la documente pas! Au lieu d accéder à cette API native, les développeurs sont invités à utiliser une autre API, dénommée API Win 32 et fournie dans KERNEL32.DLL. Cette API encapsule la native API en réarrangeant et en simplifiant parfois ses paramètres. Un simple appel système d écriture dans un fichier se transforme alors en une suite de passages de témoins comme l indique la figue suivante. L intérêt principal de ne pas documenter l API native et de devoir recourir à une API de plus haut niveau comme la Win32 API se fait surtout sentir pour les développeurs du système d exploitation: En premier lieu, les développeurs du noyau peuvent modifier les fonctions internes du noyau sans avoir besoin d en avertir les développeurs, puisque les appels systèmes ne sont pas censés être directement utilisés. Ensuite, avec une telle architecture, il est possible de supporter autant de soussystèmes différents que nécessaire, tout en faisant appel in fine aux mêmes fonctions natives ; une application Win32 pourra lancer un nouveau processus avec l appel à CreateProcess(), tandis qu une application POSIX appellera exec() ou fork(), mais, au final, c est toujours la même fonction native qui sera appelée. 16
Un micronoyau pas si micro Dans le milieu des années 1980, vers 1986-87, un groupe d ingénieurs de Microsoft, dont Dave Cutler transfuge de Digital où il exerçait en tant qu architecte du système d exploitation VMS, mirent en place un groupe de travail dont le but était de déterminer ce que serait le système d exploitation du futur. A l époque, une théorie arrêtée définissait la manière d écrire un système d exploitation portable et sécurisé ; tout le monde préconisait d utiliser une architecture fondée sur les micronoyaux. C est sur ces bases que furent conçus les premiers concepts fondateurs de Windows NT. Et pourtant, à y regarder de plus près, le système Windows 2000, bien que très largement inspiré de ce modèle, n est pas un système à micronoyau si l on se réfère à la stricte définition du concept d origine. Dans les noyaux monolithiques, comme celui de Linux, la mémoire est divisée entre l espace utilisateur et l espace noyau. L espace noyau est l endroit où le code réel du noyau réside après son chargement, et où la mémoire est allouée pour les opérations qui prennent place à son niveau. Ces opérations incluent l ordonnancement, la gestion des processus et des signaux, des entrées/sorties assurées par les périphériques, de la mémoire et de la pagination. Un micronoyau effectue un nombre bien plus restreint d opérations, et sous une forme bien plus limitée ; la communication entre processus, une gestion limitée des processus et de l ordonnancement ainsi qu une partie des entrées/sorties de bas niveau. Une architecture à micronoyau est en quelque sorte une manière de s éloigner des détails du contrôle des processus. Bien que séduisant sur le papier, les architectures à micronoyau se sont rapidement heurtées à des problèmes de performances ; comme les différents processus tournent dans des environnements cloisonnés, le facteur de performance essentiel de ce type d architecture demeurent les mécanismes de communications interprocessus et surtout les mécanismes d appels systèmes, extrêmement gourmands en ressources temporelles. Au fur et à mesure de sa conception, le système Windows NT a ainsi vu son noyau grossir de plus en plus, certains composants se retrouvant basculés du mode utilisateur au mode noyau, de telle sorte qu il n est aujourd hui plus possible de considérer le système comme un micronoyau. L exemple type de ce changement demeure la mini révolution qui accompagna le système lors de la sortie de Windows NT 4.0 en 1996. Parmi les nombreuses différences entre Windows NT 3.51 et Windows NT 4.0, il apparaît que l ensemble des mécanismes de gestion des graphismes (matérialisés par les fichiers USER.EXE et GDI.EXE) fut alors basculé, pour des raisons de performance, du mode User au mode Kernel. Une GUI dans le noyau Microsoft a eu une raison valable pour avoir déplacé les fichiers USER.EXE et GDI.EXE vers le mode noyau. Avec la nouvelle interface graphique de Windows 95, Windows NT 4.0 se voyait alourdi davantage que ses prédécesseurs. L une des conséquences majeures de l apport d une interface graphique évoluée sous Windows NT 3.51 a en effet été un ralentissement considérable du système, comparativement aux autres systèmes d exploitations semblables de l époque (Windows 3.11 notamment). Tout est dû aux très nombreux appels systèmes nécessaires pour animer une interface graphique. Avec un Pentium 90, l'accès au matériel depuis le mode utilisateur s'effectue en 70 microsecondes. Depuis le mode noyau, ce même accès s'exécute en quelques microsecondes. Le nombre d'accès a augmenté sans cesse dans la nouvelle interface et le besoin en ressources s'est accru d'autant. Sans le déplacement des fichiers USER.EXE et GDI.EXE vers le mode noyau, Windows NT aurait sans conteste accusé une extrême lenteur. 17
Effet secondaire du déplacement de ces fichiers vers le mode noyau : la diminution du besoin en mémoire de ces deux applications. L'espace ainsi économisé est rendu aussitôt à l'explorateur de Windows 95. Tout compte fait, Windows NT 4.0 ne consomme pas plus d'espace que Windows NT 3.51. L'un des dangers résultant de cette nouvelle organisation est que les routines des fichiers USER.EXE et GDI.EXE peuvent écrire désormais dans les plages mémoire des autres applications noyau. Risque principal : la paralysie de GDI.EXE peut conduire à la mort le système entier! Sous Windows NT 3.51, l'organisation était telle que GDI.EXE et USER.EXE ne pouvaient pas écrire dans le mode noyau et ne nuisaient pas à la stabilité du système d'exploitation. Pour l utilisateur dont l'application s'est bloquée, les conséquences sont graves : jusqu'à présent, seules les données de l'application ayant provoqué l'erreur étaient vouées à la perte. Désormais, les données non sécurisées de toutes les applications sont perdues car le système entier est paralysé. Les pilotes des cartes graphiques, qui étaient à l époque implémentés en mode utilisateur fonctionnent maintenant directement en mode noyau. Ils peuvent donc influencer la stabilité du système entier. Bien que ces pilotes soient les mêmes qu'autrefois, des dangers supplémentaires surgissent en mode noyau en raison de l'accès direct au matériel effectué par ces pilotes. Et les tests de sécurité n'ont été réalisés que sur les pilotes des composants figurant dans la liste de compatibilité de Microsoft 18
67?A<7<B985:4B7< :376C= #define P(X)j=write(1,X,1) #define C 39 int M[5000]={2},*u=M,N[5000],R=22,a[4],l[]={ 0,-1,C-1,-1},m[]={1,-C,-1,C},*b=N,*d=N,c,e,f,g,i,j,k,s;main(){for(M[i=C*R-1]=24;f d>=b;) {c=m[g=i];i=e;for(s=f=0;s<4;s++)if((k=m[s]+g )>=0&&k<C*R&&l[s]!=k%C&&(!M[k]!j&&c>=16!=M [k]>=16))a[f++]=s;if(f){f=m[e=m[s=a[rand()/( 1+2147483647/f)]]+g];j=j<f?f:j;f+=c&-16*!j;M [g]=c 1<<s;M[*d++=e]=f 1<<(s+2)%4;}else e=d> b++?b[-1]:e;}p(" ");for(s=c;--s;p("_"))p(" " );for(;p("\n"),r--;p(" "))for(e=c;e--;p("_ " +(*u++/8)%2))p(" "+(*u/4)%2);} & ' (!)* + +,-. Principes généraux Chaque objet du système est protégé par un descripteur de sécurité qui va définir quels types d accès vont être autorisés de la part des différentes entités. Une entité n accède pas directement à un objet, elle le fait via un processus qui fonctionne sous son identité : c est donc au niveau du processus que va être définit le contexte de sécurité qui va permettre, ou non, d accéder à des objets. Cette structure attachée aux processus s appelle un jeton. Avant de pouvoir lancer un processus, une entité doit s authentifier auprès du système. L ouverture de session définit alors le contexte de sécurité d une entité connectée à un système donné. Le modèle de sécurité de Windows 2000 repose donc sur des mécanismes d autorisation, que l on positionne sur les objets gérés par le système. L ouverture de session est gérée par la Local Security Authority, ou LSA, matérialisée par le processus LSASS.EXE ; ce processus fonctionne en mode utilisateur et assure une communication directe avec le module noyau appelé SRM (Security Reference Monitor). 1 http://www.ioccc.org/. L Internet Obfuscated C Code Contest, ou IOCCC, est un concours de programmation en langage C dont la règle principale consiste à écrire un programme le plus obscurci possible. 19
Le rôle du SRM est de valider les accès aux objets et d effectuer la journalisation des évènements de sécurité. La politique locale de sécurité d une machine (droits et privilèges des utilisateurs, classes d évènements à auditer ) est stockée dans la base de registre sous HKLM\SECURITY. L accès à un objet fait donc intervenir plusieurs paramètres : les permissions sur l objet, le jeton du processus requérant, et le composant de validation de l accès : Enfin, et afin d assurer le cloisonnement (et donc la sécurité) des processus entre eux, chaque processus évolue dans un espace mémoire qui lui est propre ; le système garantit alors le fait qu un processus ne puisse accéder à l espace mémoire d un autre processus, sauf si un privilège particulier le lui autorise. Notion de SID Au lieu d utiliser des noms (qui peuvent ne pas être uniques) pour identifier les entités qui effectuent des actions sur un système, Windows utilise des Security Identifiers (SID). Les utilisateurs, les groupes, les machines, les domaines, les membres des domaines, sont donc identifiés de façon unique par des SID. Un SID est une valeur numérique de longueur variable qui est constituée : D un numéro de révision de structure de SID D un identificateur d autorité sur 48 bits D un nombre variable de sous autorité sur 32 bits, appelées également RID (Relative Identifier) 20
La valeur de l autorité (identifier authority) identifie l agent qui a émis le SID ; cet agent est typiquement un système local Windows 2000/3 ou un domaine. Les valeurs de sous autorité identifient les «trustees» relativement à l autorité d émission et les RID sont simplement des moyens simples de créer des SID uniques sur la base d un SID de base. Etant donnée la longueur d un SID et le fait que Windows génère des valeurs aléatoires au sein de chaque SID, il est virtuellement impossible pour Windows d émettre le même SID deux fois sur des machines ou des domaines de par le monde. Lors de leur mise en forme sous forme de texte, chaque SID a un préfix sous la forme de la lettre «S» et ses différents composants sont séparés par des tirets («-») : S-1-5-21-583907252-1078145449-1957994488-500 Dans ce SID, le numéro de révision est 1, la valeur d identificateur d autorité est 5 (l autorité de sécurité de Windows 2000), on a 4 valeurs de sous autorité et un RID (500) Voici quelques règles de construction des SID : Quand on installe Windows, le programme d installation affecte à la machine un SID Windows affecte également un SID aux comptes locaux de la machine Chaque SID de compte local est basé sur le SID de la machine avec un RID différent à la fin : les RID pour les comptes utilisateur et les groupes démarrent à 1000 et sont incrémentés de 1 pour chaque nouvel utilisateur ou groupe De même Windows affecte un SID pour chaque nouveau domaine Windows. Chaque SID de domaine est basé sur le SID du domaine avec un RID différent à la fin : les RID pour les comptes utilisateur et les groupes démarrent à 1000 et sont incrémentés de 1 pour chaque nouvel utilisateur ou groupe. Certains SIDs sont réservés à des comptes (systèmes, groupes, machines ) connus. La liste exhaustive de ces SIDs pour le système Windows 2000 est présentée en annexe de ce document. Jetons d accès Une fois qu'un utilisateur a été authentifié au sein de sa session, celui-ci se voit remettre un jeton d'accès. Ce jeton est utilisé pour toute la durée de la session est n'est libéré que lorsque l'utilisateur ferme sa session. Il est utilisé pour représenter l'utilisateur dans toutes les demandes d'accès aux ressources du système. 21
Notons que ce jeton contient un certain nombre d'informations additionnelles sur l'utilisateur, et utilisées par le sous-système de sécurité de Windows NT. La table suivante précise les rôles de chacune de ces informations : Composant du jeton SID de l utilisateur SID des groupes Droits SID du propriétaire SID du groupe principal DACL par défaut Source Type Niveau d impersonation Description Représentation numérique du compte utilisateur pour identifier l'utilisateur sur le système. Représentation numérique des groupes (locaux et globaux) auxquels appartient l'utilisateur. Les droits qu'un utilisateur possède. Le SID de l utilisateur ou du groupe qui, par défaut, devient le propriétaire des objets créés avec ce jeton. Ce SID est généralement identique au SID de l utilisateur, sauf pour les comptes de type administrateur ; dans ce cas, ce SID correspond à celui du groupe «Administrateurs» Le SID du groupe principal d appartenance de l utilisation. Ce champ n est utilisé que par le soussystème POSIX. Une liste d ACLs par défaut que le système applique aux objets créés avec ce jeton et si aucune ACL n a été précisée lors de la création. L ACL par défaut accorde le Contrôle Total au créateur Propriétaire. Le processus qui a généré ce jeton (par exemple le Session Manager, le LAN Manager, ou le serveur Remote Procedure Call - RPC). Une valeur indiquant s il s agit d un jeton primaire ou d un jeton d impersonation. Un jeton primaire est un jeton qui représente le contexte de sécurité d un processus. Un jeton d impersonation est un jeton qu un thread peut utiliser au sein d un processus de service afin d adopter temporairement un autre contexte de sécurité (généralement le contexte de sécurité du client du service) Fixe le niveau d'impersonation pour le jeton d'accès, et détermine les informations qu'un autre processus dispose pour le compte d'un client (voir le chapitre 22
Composant du jeton Description traitant de l impersonation, plus loin dans ce document). Statistiques Informations utilisées en interne du système et comportant des statistiques d utilisation. SIDs restreints Une liste optionnelle de SID ajoutée par un processus disposant des privilèges de créer des jetons restreints. Un SID restreint permet de limiter les accès d un thread à un niveau de privilège inférieur à celui du processus père. ID de session Une valeur indiquant si le jeton est associé à une session Terminal Server. Les jetons contiennent aussi un champ «Expiration time» qui n est pas utilisé pour le moment. Ce champ pourrait permettre à terme la mise en place réelle de l expiration d un compte : aujourd hui, si l utilisateur reste connecté après la date d expiration du compte, le système laisse l utilisateur continuer d accéder aux ressources. Aujourd hui, la seule solution pour empêcher l utilisateur de continuer d accéder aux ressources est donc de forcer une déconnexion. Note : Windows 2000 introduit un nouveau type de jeton appelé «jeton restreint» (restricted token). Un jeton restreint est un jeton «copie» dérivé d un jeton primaire ou d impersonation, avec cette différence que certains privilèges peuvent être révoqués dans ce jeton. Ce mécanisme peut être utilisé par un thread qui souhaiterait réaliser une impersonation du client mais avec des privilèges réduits, par exemple pour du code venant d un domaine n étant pas de confiance. Il peut également être utilisé pour lancer un processus sensible avec le juste niveau de privilège requis pour son fonctionnement. kd> dt _TOKEN +0x000 TokenSource : _TOKEN_SOURCE +0x010 TokenId : _LUID +0x018 AuthenticationId : _LUID +0x020 ParentTokenId : _LUID +0x028 ExpirationTime : _LARGE_INTEGER +0x030 TokenLock : Ptr32 _ERESOURCE +0x034 ModifiedId : _LUID +0x03c SessionId : Uint4B +0x040 UserAndGroupCount : Uint4B +0x044 RestrictedSidCount : Uint4B +0x048 PrivilegeCount : Uint4B +0x04c VariableLength : Uint4B +0x050 DynamicCharged : Uint4B +0x054 DynamicAvailable : Uint4B +0x058 DefaultOwnerIndex : Uint4B +0x05c UserAndGroups : Ptr32 _SID_AND_ATTRIBUTES +0x060 RestrictedSids : Ptr32 _SID_AND_ATTRIBUTES +0x064 PrimaryGroup : Ptr32 Void +0x068 Privileges : Ptr32 _LUID_AND_ATTRIBUTES +0x06c DynamicPart : Ptr32 Uint4B +0x070 DefaultDacl : Ptr32 _ACL +0x074 TokenType : _TOKEN_TYPE +0x078 ImpersonationLevel : _SECURITY_IMPERSONATION_LEVEL +0x07c TokenFlags : UChar +0x07d TokenInUse : UChar 23
+0x080 ProxyData : Ptr32 _SECURITY_TOKEN_PROXY_DATA +0x084 AuditData : Ptr32 _SECURITY_TOKEN_AUDIT_DATA +0x088 VariablePart : Uint4B Structure exacte d un Jeton, telle que révélée par le Kernel Debugger Descripteurs de sécurité Des descripteurs de sécurité (Security Descriptors - SD) sont assignés à tous les objets sécurisables de Windows 2000, lors de leur création. Ces descripteurs sont utilisés, en interne du système d exploitation, afin de déterminer les permissions qu un utilisateur dispose sur ces objets. Les principaux objets sécurisables du système sont les suivants : Fichiers Répertoires Mappings de fichiers Pipes de communications interprocessus Mailslots Processus Threads Jetons d'accès Machines Windows Bureaux Clefs de registre Objets Services Périphériques Objets de Synchronisation (événements, mutexs, sémaphores) Objets en mode Utilisateurs Objets en mode Noyau Un descripteur de sécurité contrôle donc qui a accès à un objet, il comporte les attributs suivants : Attributs d'un Descripteur de Sécurité SID du propriétaire (Owner SID) SID du groupe Discretionary ACL (DACL) System ACL (SACL) Description L identificateur de sécurité du propriétaire de l'objet. Identificateur de sécurité du groupe principal pour l objet (utilisé uniquement par le sous système POSIX) Le DACL détermine quels utilisateurs et/ou groupes ont accès à cet objet ainsi que le type d'accès autorisé. Le SACL est utilisé pour déterminer ce qui doit être audité sur cet objet. Quand un utilisateur ou un processus requiert un accès à un objet sécurisé, le processus requérant présente d'abord son jeton d'accès au SRM qui vérifie alors les permissions sur cet objet en interrogeant le Security Descriptor de l'objet. Si les permissions positionnées ne permettent pas l'accès à cet objet ou si l'utilisateur (ou le processus) appelant ne dispose pas d'un privilège lui donnant accès à cet objet, la requête est rejetée. Dans le cas contraire, la requête est acceptée et éventuellement auditée si le SACL le précise 24
L'exemple qui suit donne les différents éléments pour le programme NOTEPAD.EXE. Ces trois fenêtres sont accessibles en cliquant sur le bouton droit de la souris sur le fichier correspondant et en sélectionnant l'option "Propriétés" ; le bouton "Avancé" propose 3 onglets, correspondant chacun aux trois figures qui suivent. Propriétaire Autorisations Audit L emplacement précis du stockage des Security Descriptors dans le système de fichiers sera décrit plus loin, dans le chapitre relatif au système de gestion de fichier NTFS. Droits des utilisateurs Sous Windows 2000, on réalise une distinction sémantique entre «droits» et «permissions». Une permission correspond à une autorisation d accès à un objet du système ; une ACL représente une permission (on parle également d autorisations). 25
Un droit est un privilège accordé à un utilisateur ou à un groupe, indépendamment de tout objet du système : par exemple, un opérateur de sauvegarde peut sauvegarder tout un répertoire même si les ACLs positionnées lui en interdisent l accès, et ce parce qu il dispose du droit «sauvegarder des fichiers et des répertoires». Lorsque l on relève un problème d accès à une ressource, si il ne s agit pas d un problème de permissions, il y a de fortes chances qu il s agisse d un problème de droits insuffisants. Détermination de l accès à un objet Un processus n accède jamais directement à un objet ; il le fait de manière indirecte en réalisant une requête auprès du noyau, qui ne renvoie pas un pointeur sur l objet mais une référence interne appelée «handle». Tous les accès ultérieurs à l objet seront alors effectués en précisant ce «handle». Ce mécanisme de «handle» permet de protéger les objets contre des accès directs à leurs structures internes. La requête initiale permettant de récupérer un handle sur un objet doit alors préciser quel type d accès il est demandé (lecture, écriture ), en passant au système un masque d accès (champ de bits dans lequel on positionne certains bits à 1 en fonction de l accès requis). Le noyau raccroche alors à ce handle le masque d accès utilisé lors de l appel initial ; il n est donc pas possible de requérir un handle sur un objet en lecture et d utiliser ce handle pour accéder en écriture à l objet Le sous-système de sécurité détermine alors si l appelant dispose des privilèges nécessaires à l exécution de sa requête. Le principe général consiste à partir d un masque dynamique vide (tous les bits à 0), puis à mettre à 1 les bits d accès de ce masque au fur et à mesure que les autorisations sont rencontrées. A la fin de l opération, ce masque dynamique est comparé au masque d accès fourni lors de l appel. Si les autorisations sont suffisantes, l accès est garanti, le handle est créé et transmis à l appelant. Précisons en outre qu une autorisation de type «déni d accès» est considérée comme une opération absorbante, annulant toute permission sur le bit considéré. 26
L algorithme de détermination de l accès est précisé ci-dessous : Si l objet ne dispose pas de DACL (pointeur nul), l objet n est pas protégé et l accès est garanti. Si l appelant dispose du droit «Prendre possession des objets», l accès est autorisé en écriture. Si l appelant est le propriétaire de l objet, l accès est autorisé pour «Lire l ACL» (READ_CONTROL) et «Ecrire l ACL» (Write DACL) Chaque ACE dans l ACL est examinée : o o o Si un déni d accès est positionné pour le(s) SID(s) de l appelant, l accès est refusé Si un accès est autorisé pour le SID de l appelant, l accès est autorisé Si la fin de l ACL est atteinte sans qu une autorisation ou un déni d accès soit rencontré, l accès est refusé 27
L impersonation Principe Lorsqu'un utilisateur accède à un programme, celui-ci s'exécute dans le contexte de sécurité de l'utilisateur. La combinaison du jeton d'accès et du programme lancé s'appelle un «Sujet». Souvent, un même «Sujet» peut être amené à appeler d'autres processus pour réaliser sa tâche, comme un processus serveur. Il peut parfois être utile qu'un processus serveur utilise le contexte de sécurité de l'utilisateur ayant fait appel à lui, plutôt que son propre contexte de sécurité, tout simplement parce qu'un processus serveur peut disposer de privilèges moindres ou supérieurs à ceux de l'utilisateur ayant fait appel à lui. Si le procédé d'impersonation n'existait pas, les requêtes à des serveurs dépendraient directement du contexte de sécurité dans lequel a été lancé le processus serveur. Ainsi, dans le cas d'une requête d'accès à un fichier, le processus serveur de fichiers peut disposer de privilèges systèmes. Si l'appel a lieu dans le contexte de sécurité du serveur de fichier, l'utilisateur pourra donc avoir accès à TOUT le système de fichiers, outrepassant ainsi les permissions restrictives qui auraient pu être positionnées sur les fichiers. Le mécanisme d'impersonation permet de contourner la difficulté en effectuant la requête dans le contexte de sécurité de l'utilisateur et donc en obligeant le serveur à réagir comme s'il était lui-même l'utilisateur ayant réalisé la requête. Sécurité du mécanisme Il est toutefois nécessaire de noter que le procédé d impersonation s effectue dans le thread et qu il est possible de mettre fin à tout moment à ce mécanisme. En d autres termes, le procédé ne permet pas de se protéger, par exemple, en cas de buffer-overflow sur le thread en impersonation. En effet, si l on traite au sein d un processus serveur (un service par exemple, avec des privilèges SYSTEM) une requête d un utilisateur en utilisant le mécanisme d impersonation, le traitement de la requête doit être exemplaire. Dans le cas contraire, le client peut alors forger une requête, en profitant par exemple d un buffer-overflow dans le passage des paramètres, et faire exécuter, par le thread d impersonation, du code injecté. L attaquant dispose alors de deux techniques pour sortir du contexte «utilisateur» du thread : Soit il provoque une sortie explicite de l impersonation en réalisant un appel à RevertToSelf(), Soit il lance un nouveau processus en réalisant un appel à CreateProcess(). 28
Dans le premier cas, on se retrouve dans le thread d impersonation, avec les privilèges du processus principal. Dans le second cas, un appel à CreateProcess() génère un nouveau processus qui, et c est le comportement par défaut du système, va alors hériter du jeton du processus principal et non du jeton du thread appelant. Les niveaux d impersonation Le jeton d accès accroché à tout processus dispose d un champ dans lequel se trouve stocké le «niveau d impersonation» que le processus propriétaire est autorisé à réaliser. Ce niveau, positionné par le système d exploitation, autorise donc le processus en cause à réaliser l impersonation selon les quatre méthodes suivantes : 29
Niveau d'impersonation SecurityAnonymous SecurityIdentification SecurityImpersonation SecurityDelegation Description Le processus serveur ne peut identifier le client. Pas de possibilité d'impersonation Le processus serveur ne peut qu'identifier le client (et donc accéder à son jeton d'accès) mais ne peut pas réaliser d'impersonation. Utile pour déterminer au niveau du serveur si un utilisateur a le droit d'effectuer telle ou telle requête : c'est alors le processus serveur qui gère les permissions et non le système d'exploitation. Le processus serveur peut identifier le client (et donc accéder à son jeton d'accès) et peut réaliser une impersonation en local. Il ne peut pas réaliser d'impersonation pour un client distant. Disponible uniquement sous Windows 2000 et 2003. Le processus serveur peut identifier le client (et donc accéder à son jeton d'accès) et peut réaliser une impersonation pour un client local et distant. Les différents types de groupes Afin de pouvoir regrouper efficacement les utilisateurs présentant les mêmes besoins, le système Windows 2000 offre la notion de groupes de sécurité. Windows 2000 définit 4 types de groupes : Groupe Local Groupe de Domaine Local Groupe Global Groupe Universel (disponible uniquement en mode natif) Dans une utilisation standard, les groupes globaux et universels servent à définir des ensembles de personnes et n'ont pas de droits et de permissions directement associées. Ils sont ensuite ajoutés à des groupes locaux, qui eux définissent les droits et permissions relatifs au domaine concerné. On trouve également la notion de groupe de distribution : il ne s agit pas d un type de groupe auquel on peut se référer dans le positionnement d ACLs, mais d un groupe particulier permettant de gérer des listes de diffusion de messagerie (avec Microsoft Exchange par exemple). Les différences entre ces groupes sont présentées dans le tableau suivant : 30
Local Domaine Local Global Universel Peut contenir Est visible de S applique à Utilisateur local Utilisateur global Groupe global Utilisateur global Machine Contact Groupe global Groupe universel Utilisateur global Machine Contact Utilisateur Machine Contact Groupe global Groupe universel La machine Du domaine De la forêt De la forêt La machine Au domaine Au domaine La forêt L API AuthZ L API Windows AuthZ a été introduite avec Windows XP et implémente le même modèle de sécurité que le SRM mais en mode user (\Windows\System32\Authz.dll). Ceci donne aux applications qui veulent protéger leurs propres objets privés (tels que des tables de base de données) la possibilité de bénéficier du modèle de sécurité de Windows sans avoir à payer le coût des transitions en mode noyau. L API AuthZ utilise des structures de données standard de security descriptor, de SID et de privilèges. Au lieu d utiliser des jetons pour représenter des clients, AuthZ utilise un contexte de sécurité particulier (le AUTHZ_CLIENT_CONTEXT). AuthZ utilise les équivalents en mode user pour tous les contrôles d accès et les fonctions de sécurité de Windows. Par exemple, AuthzAccessCheck() est l équivalent de l API AccessCheck() qui utilise la fonction SeAccessCheck() du SRM. Un autre avantage pour les applications utilisant AuthZ est qu elles peuvent demander à AuthZ de cacher les résultats des contrôles de sécurité pour améliorer les performances des contrôles suivants qui utilisent le même contexte client et le même SD. AuthZ est documenté dans le «Platform SDK», disponible sur le site Internet de Microsoft. 31
B9D3:=@<= 7!D84;<34:E:9D4:63 / % 0 12 & 3 Principes de l ouverture de session Architecture Le «logon» ou ouverture de session interactive, par opposition à l ouverture de session réseau (network logon), est une procédure obligatoire mettant en jeu de nombreux composants du système parmi : Le processus Winlogon La «Local Security Authentication Authority», implémentée par le processus LSASS.EXE, Un ou plusieurs packages d authentification «authentication packages» La SAM ou l Active Directory. 33
Chaque utilisateur doit donc procéder à une ouverture de session afin d utiliser les ressources de cette machine ou du réseau sur laquelle elle est installée. Une fois ce processus réalisé, un jeton d accès est généré, qui contient des informations de sécurité spécifique à l utilisateur concerné, entre autres : identificateur de sécurité (SID), identificateur de groupes, droits et permissions utilisateur. L utilisateur, ainsi que tout processus lancé par celui-ci, est alors identifié par ce jeton. Les packages d authentification Les packages d authentification sont présents dans le système sous la forme de DLLs implémentant les mécanismes de vérification de l authentification. Le protocole Kerberos (KERBEROS.DLL) est le package d authentification par défaut sous Windows 2000 lors d une ouverture de session interactive dans un domaine, tandis que le MSV1_0 (présent dans la MSV1_0.DLL) assure les vérifications d identité dans le cas d une ouverture de session interactive locale, lors d une ouverture de session dans un domaine pré Windows 2000 (un domaine Windows NT 4.0 par exemple) ou lorsque qu aucun contrôleur de domaine n est joignable. La GINA Dll Le Winlogon ne gère pas directement la partie graphique de l ouverture de session, qui se trouve déportée dans une librairie spécialisée appelée une GINA (Graphical Identification and Authentication). La GINA par défaut de chaque système Windows est la MSGINA.DLL, mais il est possible de coder soi-même sa propre GINA pour remplacer celle de Microsoft ; c est par ailleurs ce que font certains éditeurs de logiciels comme Novell, et ce afin d assurer l authentification depuis des machines Windows sur leur serveur Novell Netware. Fonctionnellement une GINA se présente sous la forme d une DLL exportant certaines fonctions de façon standardisée. Le processus Winlogon Le processus Winlogon est un processus de confiance initial pour toute authentification sur le système ; il assume un rôle de coordinateur des ouvertures de session, est responsable du lancement du Shell utilisateur, des changements de mots de passe et du verrouillage déverrouillage des écrans de veille. Au cours du démarrage de Windows 2000, le processus WINLOGON est lancé et crée un environnement contrôlé d'ouverture de session. Les 4 étapes décrites par la suite sont celles qui sont effectuées avant une quelconque interaction avec l'utilisateur. 1. WINLOGON crée une fenêtre sécurisée ayant un accès exclusif au système et ouvre trois environnements de travail séparés («application», «écran de veille» et «environnement du Winlogon»), puis lance le processus LSA qui charge les packages d authentification enregistrés. 34
2. WINLOGON ouvre ensuite une connexion LPC 1 vers la Local Security Authority (LSA) du système local. Cette connexion, établie par le biais des API LsaAuthenticationPort() et LsaRegisterLogonProcess(), est un canal sécurisé au travers duquel les informations d'authentification seront passées aux packages d'authentification (par défaut Kerberos.dll sous Windows 2000) à des fins de validation. 3. WINLOGON interroge alors le package d'authentification et obtient alors un numéro d identifiant pour le package installé, numéro qui lui servira pour le passage des informations d'authentification. 4. Après avoir enregistré les informations d'environnement récupérées durant les précédentes phases, la Security Attention Sequence (SAS - par défaut la combinaison de touches CTRL-ALT-DEL) est activée et l'environnement de travail est verrouillé. Une fois activée, un utilisateur peut dès lors utiliser la combinaison de touches du SAS. Ce SAS génère une interruption qui est envoyée au système ; le système réagit alors en amorçant la séquence de Logon. Dès qu'un utilisateur active le SAS, plus aucun processus ne peut alors accéder à l'environnement de travail. A ce point de la procédure, l'interface graphique d'ouverture de session est lancée et permet alors à l'utilisateur de saisir les informations relatives à l'authentification (couple login/password et type de connexion - distante ou locale). WINLOGON récupère alors ces informations et les transmet en clair, via la fonction LSALogonUser(), auprès de la LSA (LSASS.EXE) en même temps que le numéro du package d'authentification. La LSA envoie alors les données d'authentification en clair au package en question, pour vérification. Le package d authentification chiffre le mot de passe avec un algorithme différent selon le cas de figure (KERBEROS ou MSV1_0), puis interroge la base de donnée des comptes (Active Directory ou SAM). 1 Local Procedure Call Appel de Procédure Locale 35
Dans les deux cas, le package récupère et vérifie les données d'authentification avec le contenu de la base correspondante (locale ou distante) afin de déterminer si ces informations sont valides et si l'utilisateur a le droit d'ouvrir une session du type demandé. Le compte est scruté régulièrement par la suite afin de vérifier dans le temps que de nouvelles restrictions ne s'appliquent. En cas de validation, le package d'authentification poursuit son action et collecte les informations concernant le compte utilisateur parmi lesquelles : L'identificateur de sécurité de l'utilisateur (SID) Les SIDs de chaque groupe auquel appartient l'utilisateur, Le SID du propriétaire par défaut, Le DACL (Discretionnary Access Control List) par défaut Une fois ces opérations effectuées, le package d authentification passe ces informations à l'exécutif de Windows 2000 pour la création d'un jeton d'accès. Selon que la demande d'ouverture de session est locale ou distante, l'exécutif créera soit un jeton Primaire (ouverture de session locale) soit un jeton dit «d'impersonation» (ouverture de session distante). Ce jeton est alors renvoyé au package d authentification puis au LSASS.EXE afin d'initier la session utilisateur. Enfin, le processus WINLOGON crée une tâche (par défaut il s agit de «userinit.exe»), qui lance un nouveau Shell utilisateur ; par défaut, le Shell utilisateur est le programme EXPLORER.EXE 1. 1 L explorateur Windows est surtout utilisé en tant qu explorateur du système de fichier, mais sa tâche première consiste à construire le bureau utilisateur (barre des tâches, icônes, menu démarrer etc.). Pour s en convaincre, il suffit de lancer un gestionnaire des tâches et de tuer tous les processus explorer.exe ; le bureau finit alors par disparaître! 36
Ce jeton ne sert pas seulement à valider les accès aux objets du système, il est également utilisé pour identifier les actions de l utilisateur dans les journaux d événement et pour accéder aux ressources réseau. Résumé de l arborescence des processus Stockage des mots de passe dans la SAM Le système d exploitation Windows 2000 stocke les mots de passe des utilisateurs dans une base de données spécifique. Pour stocker les mots de passe des utilisateurs locaux (sous Windows 2000 Pro, Windows XP et Windows NT 4.0 Workstation) c est une base de donnée appelée SAM qui héberge ces mots de passe. Dans le cadre de l utilisation d un système Windows 2000 en domaine Windows 2000 les mots de passe des utilisateurs de domaines sont transférés dans l annuaire Active Directory. Quel que soit le cas de figure, les mots de passe ne sont jamais stockés en clair mais toujours sous une forme chiffrée. 37