1 Actualités Microsoft
1.1 Bulletins du mois de mars
Cette semaine, Microsoft a émis deux bulletins de sécurité :
- MS10-016 concerne une vulnérabilité dans Windows Movie Maker et Microsoft Producer 2003 permettant l'exécution de code arbitraire à distance ;
- MS10-017 concerne plusieurs vulnérabilités dans les produits Microsoft Excel et Microsoft Office Sharepoint Server. Leur exploitation permet également l'exécution de code arbitraire à distance.
Le CERTA recommande l'application des correctifs dès que possible.
1.2 Vulnérabilité non corrigée dans Internet Explorer
Cette semaine, le CERTA a également émis une alerte concernant les navigateurs Internet Explorer 6 et Internet Explorer 7. La faille est actuellement exploitée sur l'Internet et il est donc impératif d'appliquer les mesures détaillées dans la section « contournement provisoire » de l'alerte pour se protéger.
Le CERTA rappelle que la vulnérabilité est exploitable au moyen de plusieurs vecteurs d'attaque, notamment des sites Web spécialement conçus mais également des documents Microsoft Office. Dans ce sens, l'utilisation d'un navigateur alternatif n'est pas suffisante pour se protéger contre tous les vecteurs. En effet, cela protège un utilisateur lors de la navigation Internet mais pas lors de l'ouverture d'un document spécialement construit, par exemple. La restriction d'accès sur la bibliothèque vulnérable ou la mise à jour vers Internet Explorer 8 sont donc nécessaires pour se protéger totalement contre cette faille.
1.3 Documentation
- Alerte CERTA-2010-ALE-004 du 10 mars 2010 :
http://www.certa.ssi.gouv.fr/site/CERTA-2010-ALE-004/
2 Durcissement de la configuration des systèmes Windows : restriction des accès anonymes (3/8)
Les sessions nulles, c'est-à-dire des accès non authentifiés (le client n'a pas besoin de fournir un identifiant et un mot de passe), ont toujours été source d'accès illégitimes aux systèmes Windows. Elles doivent donc être restreintes ou désactivées, afin de se protéger contre la fuite d'information (comptes utilisateurs, partages réseau, etc.). En effet, parmi les fonctions natives d'un système Windows, les fonctions d'énumération accessibles via des interfaces RPC étaient historiquement appelables sans authentification. Ces interfaces RPC sont généralement accessibles par le mécanisme des canaux nommés (named pipes) et transportées sur le réseau au moyen du protocole SMB.
Cette recommandation s'applique tant pour les postes de travail que pour les serveurs. Il existe plusieurs dispositifs de sécurisation suivant les différentes versions de Windows.
2.1 Windows 2000
La valeur RestrictAnonymous de la clef de registre HKLM\SYSTEM\CurrentControlSet\Control\Lsa permet de définir des restrictions d'accès pour les connexions anonymes. Elle peut prendre une valeur allant de 0 à 2 :
- 0
- : aucune protection n'est activée. Il est alors possible d'accéder anonymement à de nombreuses interfaces RPC. Il s'agit de la valeur par défaut ;
- 1
- : certaines fonctions RPC, telles que celles permettant l'énumération des comptes utilisateurs et les partages réseau ne sont pas autorisées si le client ne s'est pas préalablement authentifié ;
- 2
- : aucune interface RPC accessible au moyen des canaux nommés ne peut être appelée si le client n'est pas authentifié. Cette option a posé de nombreux problèmes de compatibilité, en particulier avec des applications tierces. Elle n'a donc pas été maintenue dans les versions ultérieures de Windows.
Ce paramètre peut être configuré au travers des Options de sécurité. Sous Windows 2000, le paramètre s'appelle « Restrictions supplémentaires pour les connexions anonymes » et doit être positionné à la valeur « Ne pas permettre l'énumération des comptes et partages SAM », ce qui correspond au niveau 1 du tableau ci-dessus.
2.2 À partir de Windows XP et Windows 2003
La valeur RestrictAnonymous est toujours présente, mais seules les valeurs 0 et 1 sont possibles. En revanche, deux nouveaux paramètres font leur apparition, toujours sous la clef
HKLM\SYSTEM\CurrentControlSet\Control\Lsa :
- la valeur RestrictAnonymousSam (pouvant prendre la valeur 0 ou 1) permet d'activer des restrictions supplémentaires sur certaines fonctions RPC natives de Windows ;
- la valeur EveryoneIncludesAnonymous (pouvant prendre la valeur 0 ou 1) permet de séparer le contexte de sécurité des connexions anonymes (ANONYMOUS LOGON) de toutes les autres (Tout le monde).
Ces paramètres peuvent être configurés au travers des Options de sécurité. La liste suivante indique les correspondances entre le nom des valeurs de la base de registre et le nom de l'option dans l'éditeur de stratégie :
- RestrictAnonymous Accès réseau : ne pas autoriser l'énumération anonyme des comptes SAM : le paramètre doit être activé ;
- RestrictAnonymousSAM Accès réseau : ne pas autoriser l'énumération anonyme des comptes et partages SAM : le paramètre doit être activé ;
- EveryoneIncludesAnonymous Accès réseau : les autorisations Tout le monde s'appliquent aux utilisateurs anonymes : le paramètre doit être désactivé.
Par ailleurs, toujours dans les Options de sécurité, le paramètre Accès réseau : Permet la traduction de noms/SID anonymes autorise ou interdit la conversion anonyme des identifiants de sécurité (SID) vers le nom de l'entité associée. Ce paramètre doit être désactivé.
Enfin, au niveau des contrôleurs de domaine Windows 2003, il convient de vérifier que le groupe spécial ANONYMOUS LOGON ainsi que EVERYONE ne figurent pas dans le groupe Pre Windows 2000 Compatible Access.
2.3 À partir de Windows XP Service Pack 2 et de Windows 2003 Service Pack 1
Les paramètres décrits ci-dessous, bien que déjà présents dans les versions antérieures de Windows ou de Service Pack, ne permettaient pas de contrôler certaines valeurs implicitement positionnées par le système, réduisant ainsi leur utilité.
Ce problème est désormais corrigé, l'ensemble des valeurs étant paramétrable sous la clef
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\parameters :
- la valeur NullSessionsShare énumère les partages réseau qui sont accessibles de manière anonyme (le partage IPC$ reste toujours implicite pour des raisons de compatibilité) ;
- la valeur NullSessionsPipes énumère les canaux nommés qui sont accessibles de manière anonyme.
Ces paramètres peuvent être configurés au travers des Options de sécurité. La liste suivante indique les correspondances entre le nom des valeurs de la base de registre et le nom de l'option dans l'éditeur de sécurité :
- NullSessionsShare Accès réseau : les partages qui sont accessibles de manière anonyme : la liste doit être vide ;
- NullSessionsPipes Accès réseau : les canaux nommés qui sont accessibles de manière anonyme : la liste doit être vide.
3 La technologie DEP (Data Execution Prevention) : Administration, compatibilité et limites (3/3)
La semaine dernière nous avons détaillé la configuration de DEP, notamment avec l'ACT. Nous allons maintenant nous intéresser aux moyens disponibles pour détecter si DEP est activé. Pour finir, nous aborderons les potentiels problèmes liés à DEP ainsi que les limites de la technologie.
3.1 Recenser la configuration de DEP
Nous avons vu que le fichier boot.ini (ou l'utilisation de bcdedit) permet de définir la configuration de DEP au niveau du système. Donc un administrateur voulant connaitre la configuration de DEP pourrait créer un script pour lire ce fichier.
Cependant cela pose plusieurs problèmes :
- plusieurs entrées peuvent être présentes dans le fichier boot.ini avec des réglages de DEP différents ;
- il faut analyser (par code) le fichier boot.ini, ce qui n'est pas trivial et est potentiellement source d'erreurs.
Une méthode plus simple à gérer lorsque l'on administre un parc de machines, est d'utiliser un script WMI (Windows Management Instrumentation). Outre un script on peut aussi appeler WMI via l'outil WMIC.EXE en ligne de commande.
Dans notre cas, pour savoir quel est le réglage de DEP :
wmic OS Get DataExecutionPrevention_SupportPolicy
Cette ligne de commande renvoie une valeur de 0 à 3 qui correspond au réglage de DEP au niveau système.
La fiche technique http://support.microsoft.com/kb/912923/fr vous donnera plus de détails.
Outre WMI, on peut aussi appeler directement l'API GetSystemDEPPolicy depuis un programme.
3.2 Problème de compatibilité
Si vous activez DEP, il faudra vous assurer que cela ne pose pas de problèmes aux applications installées sur la machine. Normalement toutes les applications récentes ont été développées pour être compatibles avec DEP. Cependant, si vous avez des applications relativement anciennes installées, il se peut que certaines soient instables si vous activez DEP (notamment avec les options AlwaysOn ou OptOut).
Dans ce cas, il faudra vérifier si une nouvelle version de l'application supportant DEP n'est pas disponible auprès de l'éditeur. Dans le cas contraire vous pouvez désactiver DEP pour cette application, comme nous l'avons vu la semaine dernière.
Dans tous les cas, ces problèmes d'incompatibilité peuvent être réglés, et donc, ne sauraient justifier la décision de ne pas activer DEP.
3.3 Limites de DEP
Comme tout mécanisme de protection, DEP a ses limites et ne vous protège pas de toutes les formes d'attaques.
Plusieurs méthodes ont été développées pour contourner DEP, la plupart utilisent une variante d'une technique appelée «Return-to-libc». Le but de cette technique est d'essayer de désactiver DEP en réussissant à appeler l'une des ces API (liste non exhaustive) :
- NtSetInformationProcess
- SetProcessDEPPolicy
- VirtualProtect/ZwProtectVirtualMemory
Cependant, si DEP est couplé à la technologie ASLR (Address Space Layout Randomization), introduite dans Vista, ces techniques de contournement sont rendues plus difficiles à appliquer.
Mais ASLR a aussi ses faiblesses, comme l'ont montré les techniques utilisant le «JIT Spraying» ...
3.4 Conclusion
Malgré ses limites, la technologie DEP (surtout couplée à ASLR) rend l'exploitation de vulnérabilités significativement plus difficile. C'est une protection supplémentaire et efficace qui participe à la politique de défense en profondeur.
Le CERTA recommande donc son utilisation, bien que son activation doive être faite avec prudence sur des systèmes opérationnels.
4 Vulnérabilité dans Spamassassin Milter
Cette semaine, une vulnérabilité relative à l'extension Spamassassin Milter a été publiée. Spamassassin Milter permet d'interfacer le logiciel Spamassassin avec des serveurs de messagerie comme Sendmail ou Postfix. Historiquement cette extension fonctionnait nativement uniquement avec Sendmail en utilisant certaines macro-commandes de ce Sendmail pour communiquer. Postfix utilise d'ailleurs une couche d'émulation de ces macros afin de dialoguer avec Spamassassin Milter.
La vulnérabilité concerne l'option '-x' qui permet à spamassassin-milter de prendre en compte les éventuels alias ou utilisateurs virtuels lors du passage de message à Spamassassin. Cette option n'est normalement pas activée par défaut et doit faire l'objet d'une configuration spécifique de Spamassassin Milter.
Il est à noter que si toutefois cette option est activée, l'exploitation de la vulnérabilité devient triviale et permet l'exécution de code arbitraire à distance.
