S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 27 décembre 2013
N° CERTA-2013-ACT-052
Affaire suivie par: CERT-FR
le 27 décembre 2013

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité CERTA-2013-ACT-052

Gestion du document

Référence CERTA-2013-ACT-052
Titre Bulletin d’actualité CERTA-2013-ACT-052
Date de la première version 27 décembre 2013
Date de la dernière version 27 décembre 2013
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 – Risques liés au débridage des ordiphones

Le 22 décembre 2013, un outil permettant le débridage («jailbreak») de tous les appareils Apple fonctionnant sous iOS (des versions 7.0 à 7.0.4) a été publié. Pour rappel, ce type d’outil permet la suppression de certaines protections mises en place par le constructeur et l’installation sans restriction de programmes tiers non validés.

Les vulnérabilités utilisées nécessitent un accès physique au périphérique et ne peuvent être exploitées à distance. Aucun correctif n’est pour le moment proposé par l’éditeur.

Le CERTA rappelle que l’utilisation d’outils permettant le débridage des ordiphones n’est pas recommandée : l’installation de ces outils augmente la surface d’attaque de ces périphériques en permettant l’exécution d’applications non vérifiées et supprime certaines protections système mises en place par les constructeurs. Leur utilisation peut également annuler la garantie du constructeur.

Documentation

2 – Correction d’une technique de contournement de la protection ASLR sous Windows

Le 10 décembre 2013, Microsoft a publié la mise à jour de sécurité MS13-106 qui se distingue des mises à jour habituelles. En effet, celle-ci ne corrige pas une erreur d’implémentation mais supprime un moyen de contourner, sur les systèmes Windows, la technique de protection ASLR (Address Space Layout Randomization).

De nombreuses failles dans Internet Explorer étaient exploitées au moyen d’un composant fourni par Microsoft Office 2007 et 2010, «hxds.dll». Certains codes d’exploitation forçaient le chargement de cette bibliothèque de Microsoft Office en incluant dans la page web un lien vers une URL de type «ms-help://». Par exemple pour exploiter la vulnérabilité CVE-2013-3893, un code d’exploitation insérait le code suivant :

try { location.href = ‘ms-help://’ } catch (e) { }

Avant la publication de ce correctif, la bibliothèque n’était pas compatible avec la protection ASLR et était chargée en mémoire toujours à la même adresse de base. Une fois la bibliothèque chargée, le code d’exploitation pouvait alors s’appuyer sur des adresses statiques pour exécuter une chaîne dite «ROP» (Return Oriented Programming). La bibliothèque étant maintenant chargée en mémoire avec une adresse de base aléatoire, de nombreux exploits, y compris d’éventuels 0-days, ne peuvent plus fonctionner correctement.

Ce correctif constitue donc une mesure de défense en profondeur contre toute une catégorie de méthodes d’exploitation.

Le CERTA recommande d’appliquer ce correctif le plus rapidement possible sur tous les systèmes Microsoft Windows.

Documentation

3 – Privilégier l’utilisation du système d’exploitation Windows en 64 bits (première partie)

Depuis Windows Server 2003, Microsoft propose une version 64 bits de ses systèmes d’exploitation, permettant d’utiliser les fonctionnalités de l’architecture x64 des processeurs Intel et AMD (Note : il existe également une version Windows XP 64 bits, mais celle-ci repose en réalité sur un noyau Windows 2003).

Outre l’adressage plus important de la mémoire, un système 64 bits offre plusieurs améliorations en ce qui concerne la sécurité du système. Cet article, complété par un article à paraître la semaine prochaine, présente ces améliorations.

ASLR

Le mécanisme d’ASLR (Address Space Layout Randomization), présent nativement depuis Windows Vista et Windows Server 2008, permet de rendre aléatoire la position en mémoire des blocs de code ou de données. En rendant non prédictibles les adresses mémoire, il est moins probable qu’un code d’exploitation ciblant une vulnérabilité fonctionne dès la première tentative. Le développement de codes d’exploitation logicielle est alors plus complexe. Si cette technologie est progressivement supportée par les applications compilées en 32 bits, elle est nativement supportée par les applications compilées en 64 bits du fait de l’utilisation de compilateurs récents.

Avec Windows 8 ou 2012 en édition 64 bits, l’entropie est améliorée et l’espace d’adressage utilisé est plus important, renforçant davantage cette protection.

Protection DEP

La fonctionnalité du bit No eXecute (NX) pour les processeurs AMD ou du bit Execute Disable (XD) pour les processeurs Intel permet d’interdire l’exécution de certaines pages mémoire (par exemple pour les pages contenant des données). L’implémentation logicielle de cette fonctionnalité sous Windows se traduit par la présence du mécanisme de DEP (Data Execution Prevention). Comme l’ASLR, cette technologie est progressivement utilisée par les applications 32 bits, mais une application compilée en 64 bits va bénéficier automatiquement du mécanisme de DEP, qui plus est configuré de manière permanente, ce qui aura pour conséquence d’empêcher sa désactivation.

Avec Windows 8 ou 2012 en édition 64 bits, de nouvelles restrictions d’exécution ont été ajoutées, en particulier dans le noyau.

Signature des pilotes logiciels

Sur les systèmes Windows 64 bits, tout pilote noyau nécessite obligatoirement une signature pour être chargé par le noyau (mécanisme KMCS – Kernel-Mode Code Signing). De plus, cette signature doit être validée par une liste restreinte de certificats racines. Initialement mise en place par Microsoft avec WHQL (Windows Hardware Quality Labs) pour améliorer la stabilité de fonctionnement de son système (notamment pour répondre à la problématique d’identification de l’auteur d’un pilote mal développé), cette mesure répond à trois objectifs :

  • augmenter la difficulté de diffusion de codes malveillants au travers d’un pilote noyau logiciel. Un attaquant devra acquérir (par achat ou en le volant à une entité légitime) un certificat signé par une autorité de certification valide ;
  • détecter toute corruption de l’image d’un pilote (validation de l’intégrité du fichier binaire) ;
  • inclure obligatoirement des informations sur l’auteur d’un pilote.

Documentation

Rappel des avis émis

Dans la période du 16 au 22 décembre 2013, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 27 décembre 2013
    version initiale.