Depuis la publication du dernier CPU Oracle, on va de surprise en surprise?

Le 18 avril dernier, les administrateurs de bases de données Oracle se sont réjouis en découvrant un nombre de correctifs en nette diminution par rapport à l’édition de janvier : 39 contre 82. Il est vrai que la plupart des entreprises n’avaient pas encore fini d’appliquer les patches du CPU précédent? De plus, après être restée ouverte pendant plus de deux mois, la faille « zeroday » révélée le 26 janvier par David Litchfield était enfin traitée. Pourtant, une analyse plus poussée de ce dernier Critical Patch Update suscite quelques inquiétudes.

Pour la première fois en effet, l’éditeur a enfreint le rythme trimestriel qu’il s’est imposé. Darius Wiles, responsable chez Oracle de Security Alerts, a déclaré que certains correctifs n’avaient pas pu subir la totalité des tests afin de s’assurer de leur bonne cohabitation avec d’autres applications. En conséquence, et à la surprise générale, plusieurs failles ne disposeront de correctifs que début mai ? date finalement reportée à la mi-mai. À titre d’exemple, le correctif DB5 (qui correspond à la faille CVE-2006-1870) ne sécurise pas la totalité des versions des bases de données Oracle. Cette infraction au rythme de publication ? qui gêne bon nombre d’entreprises dans leur planification de ressources ? s’ajoute aux inconvénients provoqués par les patches de sécurité qui ont dû être réinstallés à plusieurs reprises. Ainsi, certains correctifs du CPU de juillet 2005 ont connu neuf versions différentes ! Ainsi, de faille en faille, de correctif en correctif, de « correctif de correctif » en « demi-patch », de publications régulières en non-respect des dates de mise à disposition, la vie des administrateurs chargés de la sécurisation des bases de données Oracle semble singulièrement se compliquer. Plus surprenant, le 6 avril dernier, Oracle dévoile sur son site Metalink les détails techniques d’une vulnérabilité (CVE-2006-1705) qui lui avait été signalée le 24 février 2006 par des chercheurs allemands. La page dédiée à cette vulnérabilité « zeroday », n’est resté en ligne qu’une seule journée. La faille, elle, n’est toujours pas corrigée après le CPU du 18 Avril. De plus, au fil des investigations des chercheurs indépendants, elle s’avère bien plus critique qu’initialement estimée. La société Cortina, spécialisée dans la protection des données, a publié il y a quelques jours une rétrospective de l’intégralité des CPU publiés. « Se tenir informé des failles de sécurité est une tache difficile, mais arriver à se tenir à jour des patches qui les corrigent est encore plus délicat. Les informations que nous divulguons ne concernent que l’environnement Oracle, mais nous pourrions en dire autant d’autres éditeurs », nous explique Pascal Orset, co-fondateur et responsable du développement stratégique de la SSII. Cette mise en perspective historique est truffée d’informations qui font froid dans le dos. Certes, Cortina proposant des solutions d’émulation de patches de sécurité? entre autres pour l’environnement Oracle, ce document est à lire de la même façon qu’on prend connaissance des rapports d’éditeurs d’antivirus sur les menaces potentielles des virus. Ce texte a le mérite de mettre en lumière la difficulté pour les administrateurs de base de données de concilier l’inconciliable : garantir la sécurité des données hébergées tout en assurant une disponibilité maximale.