1 Vulnérabilités des routeurs Juniper

La presse a relayé l’envoi d’un bulletin de sécurité par Juniper à ses clients pour les mettre en garde contre plusieurs vulnérabilités affectant ses produits. Ce bulletin, référencé PSN-2010-01-63 et non public, porte sur sept vulnérabilités corrigées. L’une d’entre elles permet à un utilisateur malveillant de faire s’arrêter puis redémarrer un routeur vulnérable. Elle a immédiatement attiré l’attention des spécialistes. En effet, pouvoir interrompre à distance le fonctionnement d’un routeur est considéré comme un problème critique, en particulier par les opérateurs de réseaux.

L’éditeur informe que les versions de son logiciel JunOS construites après le 28 janvier 2009 ne sont plus vulnérables.

L’application de correctifs sur des routeurs est toujours une opération délicate, nécessitant méthode et planification. Elle est rarement immédiate dans les environnements en production. Cependant, près d’un an après la publication d’une version corrigée des différentes versions maintenues par l’éditeur, ce bulletin de sécurité peut être lu comme un rappel en direction des clients.

Le maintien à jour des logiciels sur tous les composants reste un principe de base.

Documentation

2 L’avancée des attaques par PDF

Trop d’utilisateurs considèrent encore le PDF (Portable Document Format) comme un format statique et inoffensif, ce qui est loin d’être le cas, c’est même l’un des vecteurs d’attaque les plus prisés à l’heure actuelle.

La plupart des gens utilisent Adobe Reader, ce logiciel est donc la cible privilégiée des attaques par fichiers PDF. Cette tendance est renforcée par les délais de correction de la part d’Adobe. À titre d’exemple, l’alerte CERTA-2009-ALE-023 (http://www.certa.ssi.gouv.fr/site/CERTA-2009-ALE-023/) publiée le 15 décembre 2009 ne sera pas corrigée avant le 12 janvier 2010, malgré la criticité élevée de cette faille de sécurité.

Il n’est donc pas surprenant que cette faille soit actuellement activement exploitée, avec en plus une sophistication généralisée des attaques par PDF qui commencent à se rapprocher du niveau de celles utilisées dans les documents de type Compound File (format Microsoft Office notamment). Pour preuve, un document PDF apparu il y a quelques jours, exploite cette faille non corrigée de façon relativement évoluée.

Ce PDF exécute un code JavaScript construisant et injectant le payload de l’exploitation, constitué classiquement d’une zone NOP améliorée et d’un shellcode. Ce shellcode est en fait le premier étage d’un egg-hunt shellcode (shellcode à étages) et est obscurci, il est donc de taille très réduite : 38 octets. Là où l’attaque est plus évoluée, c’est dans la forme du deuxième étage du shellcode, qui est stocké comme un objet de type couleur dans le PDF et est marqué comme compressé avec FlateDecode (format de compression zlib). Ce PDF contient également deux fichiers binaires obscurcis, l’un est une porte dérobée bien connue des spécialistes : PoisonIvy, l’autre exécute Adobe Reader pour ouvrir un document PDF sain embarqué dans ce même binaire.

Lorsque ce fichier PDF est ouvert dans Adobe Reader avec le support JavaScript activé, une porte dérobée est installée sur le système et un document PDF sain est ouvert pour faire croire à l’utilisateur que tout s’est passé normalement. Pourtant l’exploitation de la vulnérabilité a bel et bien corrompu le système à la première exécution d’Adobe Reader. Ce comportement n’est pas sans rappeler celui des documents Office malveillants générés par des binders (outils automatisant la génération de documents malveillants).

Le CERTA recommande fortement l’application des solutions de contournement présentées dans l’alerte de sécurité CERTA-2009-ALE-023 (http://www.certa.ssi.gouv.fr/site/CERTA-2009-ALE-023/).

3 Alertes, correction d’alertes et avis

Cette semaine le CERTA a publié l’avis de sécurité CERTA-2010-AVI-007 qui corrige l’alerte CERTA-2009-ALE-021 concernant Adobe Illustrator. Des codes permettant l’exploitation de cette vulnérabilité étant disponibles sur l’Internet, le CERTA rappelle l’impérieuse nécessité de mettre à jour les logiciels concernés dans les plus brefs délais.

Documentation

4 Bogue de l’année 2010

Certaines applications ont été victimes d’un bogue tout-à-fait inattendu, le bogue de l’année 2010. En effet, certains programmes ne gèrent pas correctement les dates au-delà du 31 décembre 2009. C’est le cas notamment pour certaines versions des jeux de règles de SpamAssassin qui considèrent comme spam tout message électronique daté de 2010. Le problème est en fait lié à une règle vérifiant que la date du message électronique reçu n’est pas ultérieure à 2010. Ce bogue était théoriquement corrigé depuis juin 2009, mais cette correction n’a pas été répercutée par toutes les distributions.

Le produit Symantec Endpoint Protection a également rencontré des problèmes. En effet, les mises à jour des signatures de virus postérieures au 31 décembre 2009 étaient considérées comme antérieures à cette date. Ce bogue n’est pas complètement corrigé pour le moment.

D’autres applications peuvent rencontrer des problèmes. Il est difficile de tenir une liste exhaustive ou d’associer un dysfonctionnement de logiciel avec un problème de date. Un article du SANS évoque quelques incidents liés au passage en 2010.

Documentation

5 GNU/Linux et les modèles de sécurité

Traditionnellement, les systèmes d’exploitation de type GNU/Linux utilisent le concept de DAC

(Discretionary Access Control) pour définir la politique de sécurité encadrant les droits et accès aux ressources du système.

Ainsi on définit pour chaque fichier un propriétaire, un groupe et des droits qui y sont associés : lecture, écriture, exécution. On peut de cette façon écrire des règles du type, l’utilisateur ‘u’ peut exécuter le binaire ‘b’ ou encore le groupe ‘g’ peut lire et écrire dans le fichier ‘f’.

Ce mécanisme est relativement ancien et peut dans certains cas être insuffisant au regard du niveau de sécurité requis. Par exemple, un utilisateur peut très bien changer les droits des fichiers ou programmes dont il est le propriétaire. La sécurité repose alors en partie sur celle définie par les utilisateurs du système eux-mêmes. Un administrateur de système pourrait vouloir, plutôt, définir une liste explicite des autorisations par utilisateur sur les ressources du système (fichiers, périphériques, zones de la mémoire, etc.).

Pour compléter le système de DAC, il existe d’autres mécanismes comme le RBAC (Role Base Access Control) basés sur des définitions de rôles donnés aux utilisateurs. Ces rôles sont construits en fonction du système d’information par une autorité. Cette dernière donnera les accès selon les rôles aux différents éléments du système. Ainsi le patch noyau Grsecurity permet, par exemple, de définir diverses permissions sur les ressources réseau (sockets) en fonction de l’appartenance à des groupes du système : client, serveur, client/serveur.

Enfin une dernière catégorie existe : le MAC (Mandatory Access Control). Il part du principe qu’aucun accès aux ressources du système ne peut être définit par son propriétaire lui-même. Poussé à l’extrême, ce principe impose que le compte administrateur ne pourra pas tout faire sur un système en fonctionnement et sera contraint par une politique que même lui ne pourra défaire ou contourner. Sous GNU/Linux, Il existe essentiellement deux systèmes de ce type s’appuyant tout deux sur les extensions de sécurité du noyau (LSM : Linux Security Modules) : SELinux et AppArmor.

Le premier est intégré au noyau et initié par la NSA pour ses systèmes sensibles. On le trouve essentiellement dans les distributions comme Debian ou RedHat mais pas forcement de façon active.

Le second, plus récent et soutenu par Novell dans sa distribution SuSE, est mis en œuvre, maintenant, par défaut dans les dernières versions d’Ubuntu. On trouve ainsi dans cette dernière deux répertoires : /etc/appamor et /etc/apparmor.d dans lesquels sont définis des profils de sécurité par défaut relatifs à l’ensemble des ressources du système. Bien qu’assez complexe, il peut être intéressant de se pencher sur cette configuration qui apporte un gain notable du niveau de sécurité global. Ainsi, on peut y trouver des règles relatives aux navigateurs, aux lecteurs multimédia, etc.

Recommandations :

Quelque soit le choix de modèle avancé retenu pour améliorer le niveau de sécurité du système (RBAC ou MAC), il est important de bien s’attarder sur la configuration « livrée » avec la distribution. Ceci permet tout à la fois d’en connaître les limites mais également d’expliquer certains effets de bord inévitables avec ce type de fonctionnalités.

Rappel des avis émis

Dans la période du 28 décembre 2009 au 03 janvier 2010, le CERT-FR a émis les publications suivantes :