D’après une étude de la société de sécurité Sophos, l’année 2005 a vu se transformer un peu plus le paysage sécuritaire. Ainsi, deux chiffres sont particulièrement révélateurs :

• Le nombre de nouveaux virus a augmenté de 48%.
• Le nombre de programmes malicieux incluant des spywares est passé de 54,2% à 66,4%.
  

Globalement, on considère qu’un ordinateur sous Windows non protégé a 40% de chances d’être infecté par un ver internet en dix minutes d’utilisation et le phénomène n’a fait qu’empirer chaque année depuis la sortie de Windows XP. Dans un rapport financier récent, Microsoft expliquait que sa forte présence sur le marché grand public attirait un grand nombre de hackers. Il fallait pour le géant du logiciel un degré certain de réaction pour faire face à une mauvaise réputation en matière de sécurité. Vista devrait intégrer en conséquence un nombre important de mécanismes destinés à endiguer le phénomène, même si il est peu probable qu’il soit annihilé totalement (aucun système ne le peut).


Microsoft a intégré un système de comptes sur les Windows NT depuis plus de 10 ans déjà. Pourtant à l’heure actuelle, les utilisateurs se connectent toujours en administrateur. Pourquoi ? Au passage à Windows 2000 les développeurs ont conservé les vieilles habitudes du « Sur les Windows 9X, tout le monde est administrateur ». Le nombre d’applications réclamant les droits administrateurs augmentant, les utilisateurs n’avaient plus d’autre choix que de se connecter encore et toujours en administrateur.

Pour régler le tir, Windows Vista intègre l’User Account Control (UAC). Cet UAC est chargé de rendre compatible les applications qui n’ont pas réellement besoin de droits administrateurs sous un compte utilisateur. Vista va virtualiser les écritures qui ont un impact global sur le système dans la zone utilisateur. Par exemple, si une application écrit dans le dossier « program files », Vista redirige l’écriture dans le dossier Virtual Store situé dans le compte de l’utilisateur courant. Quand l’application demande ensuite ce fichier, Vista le lui fournit.


Le système utilise la même technique avec les écritures dans la base de registre. Si l’on écrit dans dans la section « HKEY_LOCAL_MACHINE->SOFTWARE », tout est redirigé sur « HKEY_CLASSES_ROOT->VirtualStore->SOFTWARE ». Sur Windows XP il est estimé que plus de 56% des applications fonctionnent correctement en compte non administrateur. Avec la virtualisation active de Vista, cette compatibilité monterait à 92%.

Sur Vista une application ne devrait nécessiter les privilèges administrateurs que si cela doit modifier l’état du système ou si elle a un impact sur celui-ci : par exemple, des antivirus, logiciels de gestion de disques ou des installeurs d’applications. Vista devrait être moins contraignant que XP sur la gestion de ces droits et un grand nombre d’actions pourra se faire en compte limité. Il serait possible d’installer certains pilotes par exemple si la police de sécurité le permet. Cela est justement permis par l’introduction de l’infrastructure User Mode dont nous parlions précédemment dans la section réservée aux pilotes.
Vista gère trois grands types de comptes :

• Le compte « Administrateur » qui correspond à une sorte de « super root ». Il possède les pleins privilèges.
• Les comptes administrateurs : les applications se lancent en droits restreints. Si une application nécessite des droits supérieurs, elle demande l’élévation des privilèges, ce qui peut se faire selon trois méthodes réglables dans les stratégies locales de sécurité :

• L’élévation silencieuse : l’application éléve elle-même ses droits sans demander l’avis de l’utilisateur.
• L’élévation par consentement : Vista demande à l’utilisateur s’il veut élever ou non l’application. Sous un compte du groupe administrateur, l’élévation par consentement est l’élévation par défaut. Il est possible cependant de changer le type d’élévation

• L’élévation par mot de passe : l’utilisateur doit entrer un nom d’utilisateur et/ou le mot de passe associé.

• Les comptes utilisateurs : les applications s’exécutent toutes en droits restreints. L’élévation par défaut est l’élévation par mot de passe et c’est la seule disponible. Sur la version finale, Vista devrait normalement proposer la création d’un compte utilisateur par défaut. Il est cependant intéressant de remarquer que le système de compte de Windows Vista protège aussi les comptes administrateurs.

Pour savoir si le système doit élever ou non les privilèges d’une application, il va utiliser certains critères :

• Une méthode heuristique de détection d’un installeur
• La présence ou non d’un manifeste en XML qui décrit les droits nécessaires pour l’application. Cette méthode sera utilisée pour les nouvelles applications compatibles Windows Vista. Dans les versions futures de Windows, l’application devra aussi être signée numériquement par un certificat Authenticode fourni par un CA agrée. Cela devrait être la seule méthode permettant de lancer une application nécessitant des droits administrateurs.
• Il vérifie une base de données de compatibilité avec d’anciens programmes.
• On peut aussi cocher la case « Lancer le programme en tant qu’administrateur » dans l’onglet compatibilité des propriétés du programme.
  

Un système de droit idéal doit restreindre au maximum les privilèges accordés à l’utilisateur. Les comptes utilisateurs restreignent d’ailleurs l’accès aux ressources mais n’ont pas d’ascendants sur le code exécuté par les applications. Dans cette optique, les nouvelles applications .Net tournent dans une machine virtuelle (CLR) et sont totalement isolées, ce qui permet d’intégrer la technologie Code Access Security (CAS). Cette technologie permet d’assigner des permissions de code à une application .Net.

Il existe environ une trentaine de permissions pour contrôler ce à quoi peuvent accéder les assemblages (fichier .exe ou .dll .Net). Le CAS permet aussi de rajouter ses propres permissions, parmi lesquelles on trouve l’accès à la base de registre, aux fichiers, aux DNS, au réseau ou au web. Le grand nombre de permissions fournit une granularité fine sur la sécurité. Ces permissions s’accordent par des polices de sécurité à partir de preuves fournies au CLR par l’assemblage. Il existe huit types de preuves :

• Le répertoire dans lequel est stocké l’assemblage
• Si le répertoire est stocké dans le répertoire GAC, qui contient les assemblages partagés par plusieurs applications
• Si l’assemblage provient d’un site web particulier
• Si l’assemblage a été fourni à partir d’une adresse hyperlien
• La zone d’où provient l’assemblage : l’Internet, un site de confiance ou un site sensible, intranet local, disque dur, etc.
• Si l’assemblage a été signé par un certificat Authenticode. Cela détermine ainsi l’éditeur de l’application
• Si l’assemblage possède un nom fort (voir la première partie)
• Si l’assemblage fournit une valeur de hachage (hash). Cette valeur est un « résumé » de tout le code de l’assemblage qui permet de fournir une identité unique de l’assemblage. Si le code est modifié, le hash calculé sera différent.
  

Si une application .Net provient de la zone Internet, elle n’aura pas accès à la base de registre ou au disque dur. Le système lui fournira par contre une permission de stockage isolé et le CLR un répertoire associé à l’application pour stocker des données. A noter qu’on pourra attribuer également un quota pour l’espace utilisé. Dans notre exemple l’application n’aura accès qu’à ce répertoire.

Le compilateur de Visual studio 2005 permet d’analyser le code de l’application et de déterminer les permissions minimales nécessaires pour l’application. Quand un assemblage est signé avec un nom fort, le CLR vérifie son identité avant chaque chargement. Si l’application a été infectée par un virus ou un malware, elle ne se lancera pas, car son identité aura été modifiée. L’isolation dans une machine virtuelle permet également d’éviter les attaques qui exploitent les failles de dépassement de tampon (buffer overflow).