Ces deux derniers mois, nos confrères d'InfoWorld (du groupe IDG, un actionnaire du Monde Informatique), ont mené des recherches sur une vulnérabilité dans le logiciel phare d'Oracle, Database, qui pourraient avoir de graves répercussions pour les clients de l'éditeur, et potentiellement compromettre la sécurité et la stabilité des systèmes reposant sur la célèbre base de données.

Généralement, quand un bug se produit suite à une défaillance dans une base de données, les systèmes affectés peuvent être restaurés à partir des sauvegardes. Mais comme InfoWorld nous l'explique dans son enquête, un ensemble de problèmes techniques pourrait entrainer des défaillances à répétition dans la base de données d'Oracle et  demander du temps et des efforts considérables pour corriger les erreurs. Selon une source qui a préféré rester anonyme, « C'est un problème très sérieux pour nous. Nous passons beaucoup de temps et dépensons beaucoup d'argent pour surveiller, planifier, et régler le problème dès qu'il se produit. »

Une enquête longue et minutieuse

Avant de rapporter ce problème, nos confrères ont effectué leurs propres tests, recoupé leurs informations avec des sources jugées fiables, et discuté à de nombreuses reprises avec Oracle, qui a reconnu qu'InfoWorld avait attiré son attention sur les aspects sécuritaires de ce problème. « Après avoir informé Oracle de nos découvertes et suite à plusieurs discussions techniques, l'éditeur nous a demandé de retenir cette information le temps de développer et de tester les correctifs relatifs à ces vulnérabilités. Dans l'intérêt des utilisateurs d'Oracle, nous avons accepté. Ces patches sont disponibles dans les mises à jour qu'Oracle a publiées au mois de janvier 2012 », expliquent nos confrères d'Infoworld qui ont réalisé un travail remarquable.

Pour être clair, l'aspect sécuritaire de la faille fait que n'importe quel client utilisant la version non patchée de la base de données d'Oracle pourrait être victime d'attaques malveillantes. Pire encore, un autre aspect, plus fondamental, pourrait poser un risque particulier pour les plus grands clients d'Oracle utilisant des bases de données interconnectées. Les deux problèmes proviennent d'un mécanisme ancré en profondeur dans le moteur de la base de données d'Oracle, avec lequel la plupart des DBA ont rarement à faire dans leur quotidien. Le coeur du problème réside dans le SCN (System Change Number), un système d'identification interne qui attribue un numéro à chaque validation de transaction : insertions, mises à jour et suppressions. Ces numéros sont attribués de manière séquentielle - sur une base temps - donc sans retour en arrière - lors de chaque modification de la base de données : insertions, mises à jour et suppressions. Le SCN est également incrémenté lors des échanges entre plusieurs SGBD liés.

Une vulnérabilité dans l'horloge interne de Database

Le SCN est crucial pour le fonctionnement de la base de données Oracle. « L'horodatage » SCN est la fonction clef pour maintenir la cohérence des données en permettant au SGBD de répondre aux requêtes de chaque utilisateur avec la version appropriée des données. Le SCN joue également un rôle important dans la consistance de la base de données car toutes les opérations de restaurations se font à partir de cet index.

Lorsque des bases de données Oracle sont reliées les unes aux autres, le maintien de la cohérence des données impose une synchronisation dans un SCN commun. Les architectes qui ont développé l'application phare d'Oracle étaient bien conscients que les SCN allaient générer un très grand nombre de numéros et ont donc intégré un générateur sur 48 bits. Soit 281 474 976 710 656 numéros attribuables. Il faudrait donc une éternité pour qu'une base de données Oracle épuise cette matrice pensez-vous ! Ajoutons qu'Oracle avait imposé une limite souple pour garantir qu'à un instant donné la valeur d'une clef SCN ne soit pas déraisonnablement élevée, ce qui indiquerait un dysfonctionnement de la base de données. Si la limite est dépassée, cette dernière peut devenir instable et / ou indisponible. Et parce que la numérotation du SCN ne peut pas être descendue ou remise à zéro, la base de données ne peut pas être restaurée à partir d'une sauvegarde. Une analogie peut être faite avec le bug de l'an 2000 sur un système non patché.