Les attaquent réussissent mieux sur les logiciels

Introduction

Un nouveau rapport sur les risques sécuritaires a été publié cette semaine. Ce rapport - intitulé « The Top Cyber Security Risks » (les principaux risques pour la sécurité informatique) – est l’œuvre conjointe des organismes de sécurité TippingPoint, Qualys, et SANS. Nous allons aborder, dans cet article hebdomadaire sur la sécurité, un point particulier de ce rapport – les correctifs logiciels.

Les résultats de cette étude semblent indiquer que les entreprises ainsi que les utilisateurs individuels doivent modifier/mettre à jour leur régime d’application des correctifs afin de renforcer leur sécurité.

Les vulnérabilités des logiciels – un risque majeur pour la sécurité

Nous avons rédigé, ces dernières années, plusieurs articles sur la sécurité traitant du fait que les programmeurs de nuisances utilisent les vulnérabilités des systèmes d’exploitation et des applications pour diffuser des nuisances et/ou accéder aux informations confidentielles. Le rapport cité ci-dessus met en évidence quelques statistiques intéressantes à ce propos :

• les vulnérabilités des applications reçoivent moins d’attention et sont corrigées à un rythme plus lent que les vulnérabilités des systèmes d’exploitation ;
• on découvre plus de vulnérabilités dans les applications que dans les systèmes d’exploitation.

Une vulnérabilité peut impliquer, au moins, trois entités différentes :

1. L’éditeur du logiciel, qui est l’auteur du programme qui contient la vulnérabilité, et qui doit fournir un correctif dès qu’il a connaissance de cette dernière.
2. La personne et/ou l’organisation qui découvre la vulnérabilité, et qui peut la reporter ou non à l’éditeur du logiciel. Cette entité peut également exploiter cette faille à l’aide d’une nuisance ou par un autre biais.
3. La personne et/ou l’organisation qui utilise le logiciel contenant la vulnérabilité. Si l’éditeur fournit un correctif, elle peut choisir de l’installer ou non.

Les considérations liées au point 2 exposé ci-dessus impliquent également la notion de publication éventuelle de la vulnérabilité, que nous abordons, par exemple, dans cet ancien article.

Toutefois, nous nous concentrerons, cette fois, sur les deux autres éléments de la liste ci-dessus.

Les vulnérabilités des applications reçoivent moins d’attention et sont corrigées à un rythme plus lent que celles des systèmes d’exploitation

Ce point du rapport n’est pas surprenant. On peut présumer de la justesse de cette observation, car :

• Si le paramétrage du système d’exploitation l’autorise, ses mises à jour sont souvent téléchargées et même installées automatiquement.
• En général, les vulnérabilités des systèmes d’exploitation intéressent plus les médias que celles des applications ; la nécessité des mises à jour est donc, dans ce cas, plus évidente.
• Les personnes responsables de la sécurité informatique au sein d’une entreprise se concentrent en priorité (et à juste titre) sur les vulnérabilités risquant de se propager rapidement et non sur celles qui ne sont présentes que sur quelques ordinateurs (toutes les machines sont équipées d’un système d’exploitation, mais toutes n’emploient pas une application spécifique).

La connaissance de ces faits peut attirer l’attention de l’auteur de nuisances moyen, pour peu qu’il ait l’esprit rationnel. Au lieu de concentrer ses efforts sur les vulnérabilités des systèmes d’exploitation – qui ont un potentiel énorme sur une très courte durée – il est probablement plus sage, de son point de vue, de se concentrer sur les failles des applications très diffusées. Le nombre d’installations est plus réduit, mais il est probablement possible de réussir à exploiter les vulnérabilités pendant une plus longue période.

Ajoutez ensuite l’observation mentionnée ci-dessus : la mise à jour des applications est souvent fastidieuse. Certaines applications n’intègrent aucun mécanisme de mise à jour automatique, mais reposent sur une installation complète de la nouvelle version (dans certains cas, il faut même retirer totalement la version vulnérable avant d’installer la nouvelle). D’autres doivent être paramétrées manuellement pour rechercher des mises à jour. D’autres encore disposent de mécanismes de mise à jour leur permettant de rechercher, de temps à autre, les nouvelles versions. Enfin, certaines applications ne disposent d’aucun système permettant d’informer l’utilisateur de l’existence d’une nouvelle version (plus sûre).

Par conséquent, les logiciels nuisibles visant les applications (populaires) subsistent généralement des mois, voire des années après la mise à disposition par l’éditeur d’une version sécurisée et/ou d’un correctif pour la vulnérabilité.

On découvre plus de vulnérabilités dans les applications que dans les systèmes d’exploitation

Bien sûr, cet état de fait peut être lié au fait que les systèmes d’exploitation sont plus sûrs que les applications. Cela pourrait être vrai.

Toutefois, nous pensons que la raison principale de cette situation est que les « voyous » savent que la fréquence de correction des applications est plus espacée, comme nous l’expliquions ci-dessus. Les efforts déployés pour la recherche d’une vulnérabilité dans une application populaire seront plus payants car la nuisance qui l’exploitera aura une plus grande espérance de vie.

Tant que cette situation perdurera, l’exploitation des vulnérabilités des applications prévaudra – au moins pour les applications très répandues.

Trop de technologies de mise à jour

Comme nous l’avons mentionné ci-dessus, il n’existe aucune norme de mise à jour des applications.

On pourrait nous rétorquer que les éditeurs de systèmes d’exploitation (tels que Microsoft) offrent des mécanismes de mise à jour similaires pour leurs applications et leurs systèmes d’exploitation. On peut également dire que, dans certains cas, les applications proposées par le même éditeur disposent de systèmes de mise à jour identiques ou similaires. Il reste cependant vrai qu’il n’existe aucun mécanisme de mise à jour commun aux éditeurs ou aux applications.

Systèmes de gestion des correctifs

Cet état de fait a engendré une nouvelle gamme de produits qui tentent de remédier à ce besoin – les systèmes de gestion des correctifs et des mises à jour. Il existe plusieurs systèmes, et les entreprises qui font l’effort de les acheter, de les installer et de les mettre à jour (sic !), travaillent avec des applications plus sûres que celles qui n’ont mis en place aucun régime d’installation des correctifs et des mises à jour.

Les plus petites organisations et surtout les particuliers ne peuvent généralement pas bénéficier de ces systèmes pour des raisons économiques.

Vérification d’une application à partir d’une autre

Il est intéressant de noter que le projet Mozilla, qui est responsable du développement du très populaire navigateur Firefox, a annoncé ce mois ci que la nouvelle version de Firefox intégrera des systèmes permettant d’alerter les utilisateurs si la version de leur module Adobe Flash Player pour Firefox est périmée. C’est un exemple d’éditeur d’applications qui se sent responsable de la protection des utilisateurs contre les vulnérabilités des produits des autres éditeurs.

Initiative des éditeurs de systèmes d’exploitation ?

Certains ont évoqué le fait qu’il incombe aux éditeurs de systèmes d’exploitation de développer un système commun de mise à jour des applications – qu’il s’agisse des correctifs, des mises à jour générales du programme ou des deux.

Un tel système pourrait être une API (Application Programming Interface ou interface de programmation d’applications) que les programmeurs utiliseraient pour que le système d’exploitation accède aux mécanismes de mise à jour du produit. Les utilisateurs et les administrateurs informatiques pourraient alors établir des plans de mise à jour à partir d’une interface unique, comme ils le font lorsqu’ils accomplissent un paramétrage d’ordre général.

Références

• The Top Cyber Security Risks (Les principaux risques pour la sécurité informatique, rapport de septembre 2009 intégrant des données et analyses émanant de organismes TippingPoint, Qualys, et SANS)