Agence nationale
de la sécurité des
systèmes d'information
No CERTA-2001-INF-004
| S . G . D . S . N Agence nationale de la sécurité des systèmes d'information |
|
Paris, le 04 octobre 2001 No CERTA-2001-INF-004 |
Affaire suivie par :
CERTA
Objet : Acquisition des correctifs
| Conditions d'utilisation de ce document : | http://www.certa.ssi.gouv.fr/certa/apropos.html |
| Dernière version de ce document : | http://www.certa.ssi.gouv.fr/site/CERTA-2001-INF-004 |
Une gestion de version détaillée se trouve à la fin de ce document.
Parmi les questions fréquemment posées au CERTA figure une inquiétude légitime concernant la confiance à accorder dans les correctifs à appliquer pour contrer une vulnérabilité. Cette inquiétude regroupe un ensemble de questions plus ou moins corrélées :
Dès lors que l'on a obtenu par un canal sûr, les correctifs de la part de l'éditeur, la confiance dans le correctif se ramène à la confiance que l'on peut avoir dans l'éditeur.
Il n'y a aucune raison objective de soupçonner que les correctifs apporteraient plus ou moins de fonctions cachées que le système d'exploitation ou l'application qu'ils corrigent. Vous pouvez vous forger une opinion sur le degré de sécurité apporté par un logiciel au regard de vos besoins de sécurité en demandant une évaluation du produit.
Indépendamment de toute suspicion que l'on pourrait éprouver à l'égard de tel ou tel éditeur de logiciel, il convient de se rappeler qu'un correctif est souvent un logiciel (c'est plus rarement de la documentation ou des données de configuration). Or l'état de l'art en matière de développement fait qu'on ne sait pas faire du logiciel sans défaut (même en appliquant des méthodes de développement basées sur une pratique mûre du génie logiciel, on parvient à abaisser le taux de défauts à une fourchette comprise entre 0,1 et 1 défaut par millier de lignes de code, ce qui est considéré comme un exploit en matière de qualité).
Les personnes qui développent des correctifs travaillent bien souvent avec un objectif très serré. Il s'agit d'une course entre eux et les pirates. En effet, dans le but d'inciter les éditeurs à corriger rapidement leurs logiciels, il existe des forums où les défauts sont mis sur la place publique. Il arrive que pour prouver la nocivité de la vulnérabilité, quelqu'un publie un programme qui l'exploite pour permettre par exemple d'acquérir des privilèges. Ces forums, y compris les plus sérieux, disposent d'une politique de divulgation qui, pour simplifier, pose un ultimatum aux éditeurs : « vous avez 45 jours pour publier votre correctif. Dans tous les cas nous publierons la vulnérabilité passé ce délai. Votre réputation est en jeu. » Il n'y a pas de consensus sur le bien fondé de cette politique de divulgation, certains pensent qu'il serait préférable de cacher la vulnérabilité avant qu'elle ne soit corrigée, la majorité des spécialistes pensent qu'il est illusoire de cacher la vulnérabilité ; la divulgation est l'aiguillon qui pousse l'éditeur à corriger son produit.
Cette pression sur les développeurs peut dans certains cas ne pas les placer dans les conditions les meilleures pour un développement sûr. Ainsi certains correctifs font l'objet de plusieurs versions ce qui aurait tendance à prouver la difficulté d'appréhender complètement un problème du premier coup.
Dans tous les cas, les correctifs peuvent entraîner des effets de bord. Un effet souvent constaté est le changement des éléments de l'interface homme-machine qui ne sont plus rédigés en français. D'autre part, certains correctifs récents s'appuient sur d'anciens composants logiciels (bibliothèques de fonctions partagées par exemple), réintroduisant ainsi une vulnérabilité que d'autres correctifs avaient entre temps supprimée.
Non.
Les protocoles de l'Internet généralement utilisé pour accéder aux correctifs en ligne (FTP, HTTP) ne sont pas fiables. En effet, il est possible de détourner le DNS pour faire miroiter un faux site de téléchargement de correctifs. Il existe des outils servant à la sensibilisation au risque informatique qui font cela très bien.
Rien donc ne prouve que vous obtenez le correctif de la part de l'éditeur, à moins que celui ait mis en œuvre des procédés cryptographique qui permettent d'authentifier les serveurs (SSL) et d'authentifier les fichiers (signature PGP ou GPG en général). Ces deux techniques ne sont pas exclusives l'une de l'autre. On peut aussi obtenir par un canal non sûr les fichiers de correctifs et par un canal sûr les condensés MD5 de ces fichiers.
Cependant ces techniques cryptographiques pour être efficaces doivent faire l'objet d'une attention particulière. On peut citer deux cas ou des éléments cryptographiques ont été compromis. Le premier cas, le plus célèbre est celui d'un faux certificat SSL au nom d'un grand éditeur de logiciel signé par une autorité de certification non moins célèbre ; l'autre cas est celui d'un serveur compromis chez un autre grand éditeur, l'obligeant à révoquer certaines de ses clefs PGP. Par ailleurs la confiance dans le protocole SSL, nécessite une compréhension des mécanismes sous-jacents.
Vous ne pourrez avoir confiance dans le mécanisme de téléchargement que lorsque vous êtes en relation avec un éditeur qui applique une signature des fichiers que vous pouvez vérifier parce que la clef de signature est sur un cédérom d'installation, par exemple (ou tout autre canal sûr de distribution de leur clefs), et que les procédures de gestions, par l'éditeur, de ses clés secrètes vous semblent sérieuses.
Non.
La première raison est qu'il appartient à l'éditeur du logiciel que vous avez choisi d'offrir un service de maintenance à la hauteur de ce que vous attendez. Cela peut constituer un critère de choix important dans l'acquisition d'un logiciel.
Le CERTA est confronté au même problème que chaque administrateur. S'il doit acquérir le correctif en ligne, il est soumis aux mêmes aléas.
La seconde raison est liée à la propriété intellectuelle. Les éditeurs assimilent souvent à de la contrefaçon quiconque prétend proposer leur logiciel, voire leurs avis de vulnérabilité recopiés verbatim sur un serveur WEB.
En revanche le CERTA a déjà et pourra être amené à diffuser des logiciels qu'il a écrit ou modifié lui-même.
C'est une question extrêmement pertinente.
La réponse n'est pas aisée et s'apprécie au regard de votre politique de sécurité. Toutefois la problématique peut se résumer en : « dois-je prendre le risque d'être compromis, intentionnellement ou non par mon fournisseur de logiciel, pour échapper à la certitude d'être compromis par un virus ou un pirate ? ».
Il semble que la réponse se ramène au choix suivant :
Personne ne vous empêche de tester le correctif sur une machine dont l'importance est moindre pour évaluer les éventuels effets de bord qui pourraient apparaître dans votre contexte d'utilisation.
Toutefois, certains vers récents étant très agressifs, une machine connectée à Internet peut subir plusieurs dizaines voire centaines de tentatives d'exploitation de vulnérabilité par jour. Si bien qu'en restant connecté (ou dans n'importe quelles conditions de promiscuité informatique, comme de fréquents échanges de disquettes par exemple) vous multipliez vos chances d'être compromis.
La compromission sera un moindre mal, puisque vous ne placez pas de données sensibles sur une machine connectée à Internet, n'est-ce pas ? D'autre part votre service juridique est prêt à traiter les plaintes qui pourraient survenir de tiers dont la machine serait agressée par la vôtre suite à une compromission utilisant la vulnérabilité pour laquelle vous ne souhaitez pas appliquer des correctifs acquis de façon non sûre.
Dans ce cas vous pouvez laisser la machine branchée en espérant que les correctifs soient sur le prochain cédérom de maintenance (ou tout canal qui vous semble suffisamment sûr).
En conséquence le CERTA ne peut pas prendre la décision à votre place, dans la mesure ou aucune des solutions n'est totalement satisfaisante et que la pondération des différents risques dépend de vos besoins. Le rôle d'un CERT est de vous avertir de l'agressivité de certains logiciels malveillants ou bien de vulnérabilités qui pourraient être exploitées et de signaler les correctifs qui, a priori, remettent en cause le moins possible vos choix d'architecture de sécurité.