S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 10 août 2015
N° CERTFR-2015-ACT-032
Affaire suivie par: CERT-FR
le 10 août 2015

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité CERTFR-2015-ACT-032

Gestion du document

Référence CERTFR-2015-ACT-032
Titre Bulletin d’actualité CERTFR-2015-ACT-032
Date de la première version 10 août 2015
Date de la dernière version 10 août 2015
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 – Bénéfices des RODC

Introduction

Afin de répondre à certaines problématiques de sécurité, les RODC (Read-Only Domain Controllers) sont aujourd’hui de plus en plus répandus en environnement Active Directory. Cependant, leur intérêt est souvent mal compris et ils sont rarement utilisés et configurés de manière satisfaisante. Par exemple, il est fréquent d’observer des RODC utilisés comme serveur mandataire vers un RWDC (contrôleurs de domaine « complets », par opposition aux RODC) afin d’en limiter l’exposition et la surface d’attaque, ce qui ne fait pas partie des cas d’usage des RODC et vient complexifier l’administration du domaine sans apport de sécurité.

Cet article se propose donc de détailler les intérêts réels des RODC, de donner des détails techniques quant à leur configuration, puis de formuler des recommandations à l’usage des RODC.

Présentation et intérêts des RODC

Les RODC sont des contrôleurs de domaine, pour lesquels on observe les différences suivantes :
  • ils possèdent des partitions de l’annuaire AD en lecture seule ;
  • ils possèdent une copie du SYSVOL en lecture seule ;
  • ils n’effectuent pas de réplication sortante avec les autres DC, c’est-à-dire qu’aucun RWDC ne réplique depuis un RODC ;
  • ils possèdent une copie « filtrée » de l’annuaire : certains attributs ne leur sont jamais transmis et les attributs secrets (les plus sensibles d’un domaine, comme ceux contenant les empreintes de mot de passe) ne leur sont transmis que pour certains comptes explicitement autorisés, par défaut aucun.

Ainsi, du point de vue de la sécurité, un RODC doit permettre de limiter la compromission d’un domaine à la surface gérée par le RODC compromis, sans entraîner la compromission totale du domaine. Un attaquant ne pourra pas en effet créer, modifier ou supprimer des informations dans l’annuaire ou dans le SYSVOL de manière globale au domaine, et ne pourra également pas récupérer d’attributs sensibles ou secrets suite à l’extraction de la base contenant les données de l’annuaire AD d’un RODC (« ntds.dit »).

Cependant, cette sécurité n’est effective que dans certains cas d’usage, et d’après les documentations Microsoft, les intérêts des RODC sont les suivants :

  1. installer un contrôleur de domaine sur un site pour lequel la sécurité physique n’est pas garantie ou d’un niveau de confiance moindre ;
  2. déléguer l’administration d’un contrôleur de domaine à un administrateur sur un périmètre restreint, n’ayant pas d’autres privilèges particuliers sur le domaine, permettant ainsi de ne pas étendre les groupes privilégiés d’administration du domaine (au contraire d’un RWDC, sur lequel il n’est pas possible de dissocier « administrateur local du DC » et « administrateur du domaine ») ;
  3. permettre l’authentification d’une population d’utilisateurs spécifiques sur un site distant disposant d’un lien réseau faible (ou subissant des coupures avec le SI principal), sans avoir à y déployer un RWDC ;
  4. alléger la réplication des RWDC centraux dans certaines topologies en étoile où ces contrôleurs de domaine possèdent de nombreux partenaires de réplication.

Dans un prochain article, nous aborderons les détails techniques et la configuration des RODC.

2 – Vulnérabilités dans le cadriciel StageFright

De multiples vulnérabilités affectant le cadriciel multimédia « StageFright » du système Android ont été découvertes par Joshua Drake, chercheur à l’entreprise Zimperium Zlabs.
Ces vulnérabilités affectent toutes les versions du système Android depuis 2.2 (Froyo).
Le chercheur a identifié des vulnérabilités de type « dépassement d’entier » permettant d’exécuter du code arbitraire à distance. Les plus critiques affectent le parseur mpeg4 de StageFright.
Les vecteurs d’attaques sont multiples et il est possible d’exploiter un appareil à distance sans aucune interaction de la part de l’utilisateur. La disposition stochastique de l’espace d’adressage (ASLR) à partir des versions 4 d’Android rend l’attaque plus compliquée mais néanmoins possible.

L’exploitation de la vulnérabilité sur l’appareil peut se faire via :

  • la réception d’un MMS contenant le média malveillant,
  • la visite d’une page web contenant le fichier incrusté,
  • le chargement du fichier mp4 malformé avec un lecteur multimédia quelconque.

Cette vulnérabilité pourrait permettre d’installer une application malveillante sur un appareil Android de manière furtive.

Analyse de la vulnérabilité CVE-2015-3827

Une vulnérabilité de type « dépassement d’entier » affecte la fonction « MPEG4Extractor::parseChunk » du parseur mpeg4 lors du traitement de l’atome « covr ».
Dans le code ci-dessous, la valeur de la variable « chunk_data_size » n’est pas vérifiée. Si cette valeur vaut la taille maximale d’un entier, le tampon alloué sera de taille nulle. Si la valeur de « chunk_data_size » est inférieure à kSkipBytesOfDataBox (donc 16), une très grande valeur (correspondant à la taille de la donnée à copier) sera passée en argument à la méthode MetaData::setData, ce qui pourra provoquer un dépassement de tampon sur le tas. 
case FOURCC(‘c’, ‘o’, ‘v’, ‘r’):
{
        […]
        sp<ABuffer> buffer = new ABuffer(chunk_data_size + 1);
        […]
        const int kSkipBytesOfDataBox = 16;
        mFileMetaData->setData(KeyAlbumArt, MetaData::TYPE_NONE,
        buffer->data() + kSkipBytesOfDataBox, chunk_data_size – kSkipBytesOfDataBox);
        […]

}
La variable chunk_data_size est définie plus haut dans lecode. 
off64_t data_offset = *offset + 8;
[…]
off64_t chunk_data_size = *offset + chunk_size – data_offset;
Pour que chunk_data_size puisse être égale à MAX_SIZE,chunk_size doit être égale à 0xFFFFFFFF + 8 car : 
*offset + chunk_size – data_offset == 0xFFFFFFFF
*offset + chunk_size – (*offset+8) == 0xFFFFFFFF
chunk_size – 8 = 0xFFFFFFFF
La variable chunk_size est définie au début de lafonction : 
uint64_t chunk_size = ntohl(hdr[0]);
Cette variable est contrôlable par l’attaquant car hdr[0]correspond aux 4 premiers octets de l’atome. 
if (chunk_size == 1) {
        if (mDataSource->readAt(*offset + 8, &chunk_size, 8) < 8) {
                return ERROR_IO;
        }
        chunk_size = ntoh64(chunk_size);
        data_offset += 8;
[…]
}

D’après la documentation du format mpeg4, l’atome correspondant à l’ajout d’une illustration au fichier est constitué de :

  • la taille de l’atome (4 octets),
  • l’étiquette (4 octets),
  • la taille de la donnée qui suit (8 octets),
  • la donnée.

Pour exploiter la vulnérabilité, il faut que la taille de l’atome soit égale à 1 et que la taille de la donnée (à la position suivant le tag ‘covr’) soit égale ou supérieure à 0xFFFFFFFF. La lecture du fichier modifié provoquera un plantage du service mediaserver

%F/libc (13326): Fatal signal 7 (SIGBUS) at 0x41414141 (code=1), thread 13340 (Binder_1)
%I/DEBUG ( 271): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
%I/DEBUG ( 271): Revision: ‘p2d0’
%I/DEBUG ( 271): pid: 13326, tid: 13340, name: Binder_1~>>> /system/bin/mediaserver <<<
%I/DEBUG ( 271): signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 41414141
%W/NativeCrashListener( 989): Couldn’t find ProcessRecord for pid 13326
%I/DEBUG ( 271): r0 41414141 r1 b58cf180 r2 ffffffff r3 41414141

Recommandations

Il est recommandé d’attendre qu’un correctif de sécurité soit disponible afin de corriger ces vulnérabilités et de se référer à l’alerte publié par le CERT-FR (voir documentation) pour appliquer des mesures préventives en attendant la disponibilité d’un correctif.

Il est possible de vérifier si un appareil est vulnérable en utilisant l’application « StageFright Detector App » disponible sur le « Google Play Store ».

Documentation

Rappel des avis émis

Dans la période du 03 au 09 août 2015, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 10 août 2015
    version initiale.