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é.

[[page]]

La limite imposée par Oracle découle d'un calcul très simple avec un seuil ancré dans le temps il y a 24 ans. Prenez le nombre de secondes depuis le 01/01/1988 à 00:00:00 et multipliez ce chiffre par 16 384. Si la valeur actuelle du SNC est inférieure à cela, alors tout va bien et le traitement continue normalement. Pour mettre cela en termes simples, le calcul suppose qu'avec une base de données fonctionnant en permanence depuis le 01/01/1988, il est impossible dans la réalité d'arriver à 16 384 transactions par seconde.
Mais il est toujours possible de modifier les conditions de cette réalité pour repousser la limite du SNC.

Le bug de sauvegarde

Un exemple récent vient sous la forme d'un bug de la base de données Oracle avec la fonction qui assure les sauvegardes live. Elle permet à un administrateur d'exécuter une commande afin de faciliter la sauvegarde d'une base de données en direct. C'est une fonction très pratique qui peut être exécutée facilement : «ALTER DATABASE BEGIN BACKUP » est la commande dont vous avez besoin. Vous pouvez ensuite sauvegarder la base jusqu'à ce que vous saisissiez la commande « ALTER DATABASE END BACKUP» qui switche sur le mode de fonctionnement normal. Un moyen très simple pour un administrateur de faire des sauvegardes de ses bases de données en production.

Le problème est que, en raison d'un codage défaillant, la commande «BEGIN BACKUP » entraine un bond spectaculaire du SCN qui continuera d'augmenter à un rythme effréné même après la saisie de la commande « END BACKUP » . Ainsi, effectuer une sauvegarde à chaud peut augmenter de plusieurs millions ou mêmes milliards la  valeur du SCN. Dans la plupart des cas, les limites du SCN sont si éloignées que ce saut occasionnel n'est pas une cause de préoccupation majeure. Il est même certain que bien peu d'administrateurs ont remarqué le problème.

L'interconnection des bases multiplie l'effet du bug SCN

Mais quand vous mélangez le bug de sauvegarde live avec un grand nombre de bases de données interconnectées dans une mise en oeuvre massive de la plate-forme d'Oracle, la combinaison peut entraîner une élévation énorme du SCN. Certains grands clients d'Oracle ont des centaines de serveurs exécutant des centaines d'instances Database interconnectées dans toute l'infrastructure. Chacun peut être chargé avec un service de base et quelques fonctions moins importantes - mais presque tous sont reliés entre eux, à travers un, deux, quatre ou plus de serveurs intermédiaires.

Avec tous ces serveurs interconnectés, les SCN se synchronisent à un moment ou un autre. Collectivement, ils pourraient dépasser les 16 384 transactions par seconde, mais certainement pas depuis le 01/01/1988, donc la limite SCN n'est pas dépassée. Mais que faire si une DBA sur une partie de ce réseau Oracle gère la sauvegarde live et déclenche le précédent bug ? Soudain, le SCN fait un bond de, disons 700 millions, et ce nombre devient bientôt la référence pour tous les SCN interconnectés sur le réseau. Quelque temps plus tard, une autre commande de sauvegarde live est enclenchée par un DBA de l'autre côté de l'entreprise. Le SCN pousse jusqu'à quelques centaines de millions cette fois-ci, également synchronisé sur toutes les instances reliées au fil du temps.

Avec l'émission de quelques commandes de sauvegarde, le SCN d'un groupe de bases de données Oracle peut augmenter de plusieurs centaines de millions, voire de centaines de milliards dans une courte période. Même les SGBD qui se relient occasionnellement, par semaine ou par mois, pourraient voir leur nombre SCN bondir de plusieurs milliards.
Dans un tel scénario, ce n'est qu'une question de temps pour que les commandes de sauvegarde dépassent la limite du SCN et entrainent des problèmes très sérieux, blocage des requêtes provenant d'autres serveurs, ou plantages tout simplement.

[[page]]

Oracle a publié un correctif pour le bug du SCN lors des sauvegardes avant que l'équipe d'InfoWorld commence à enquêter sur cette histoire. Le bug de sauvegarde est répertorié comme le 12371955 : «  croissance élevée du SCN ALTER DATABASE BEGIN BACKUP dans 11g. » Si vous n'avez pas déjà installé ce patch, Oracle recommande une installation immédiate.

Jusqu'à récemment, en dehors de la correction du bug de sauvegarde, la seule réponse d'Oracle à la question de la limite du SCN - pour autant que nous avons été en mesure de déterminer - a été de publier un patch qui étend le calcul de SCN à 32 768 fois le nombre de secondes depuis le 01/01/1988, doublant ainsi la taille de la limite. Oracle a même rendu modifiable cette limite, les administrateurs peuvent encore augmenter le multiplicateur. Si ce patch est appliqué à une instance d'Oracle, il va alléger le problème du SCN. Toutefois, il introduit aussi de nouvelles variables.

Impossible de patcher tous les serveurs en même temps

Une partie du problème est que vous ne pouvez pas mettre à jour tous les systèmes en même temps. De plus, si vous avez un système patché avec une limite d'élévation - basé sur un multiplicateur de, disons, 65 536 - le SCN sur ce système pourrait être plus élevé que le SCN sur un système non patché utilisant le multiplicateur de 16 384 d'origine. Le système non patché pourrait  donc refuser la connexion. Il y a aussi la question des serveurs exécutant d'anciennes versions d'Oracle qui ne bénéficieront pas de correctif.

Par ailleurs, si ce patch est inclus par défaut dans la prochaine version d'Oracle Database, les administrateurs vont peut-être soudainement découvrir que leurs anciens serveurs sont incapables de communiquer avec les serveurs dotés de la version bénéficiant d'une méthode de calcul plus élevée pour le SCN. Pire, ils pourraient s'aligner sur les nombres du nouveau système de calcul, mais en gardant leur limite d'origine. Comme mentionné précédemment, le risque d'un tel scénario est très faible, sauf dans les environnements hautement interconnectés où un SCN élevé peut plomber un serveur à la manière d'un virus. Et une fois le serveur infecté, il n'y a aucun retour en arrière possible. Aussi, si le SCN est incrémenté arbitrairement - ou manuellement, avec une intention malveillante - alors la limite des 48 bits ne sera pas aussi astronomique qu'on le pensait au début de ce papier.

Un point préoccupant pour les utilisateurs

La rédaction d'InfoWorld a contacté des utilisateurs américains de la base de données d'Oracle pour parler de ce problème. Plusieurs de ces interlocuteurs n'étaient pas familiers avec le sujet; d'autres ont indiqué que les accords de licences Oracle les empêchent de faire des commentaires sur tout aspect de leur utilisation des produits de l'éditeur. Le chef de l'Independent Oracle User Group (IOUG), Andy Flower, a simplement indiqué au sujet de ce dossier: « Ce bug avec les numéros du SCN est évidemment un point qui préoccupe nos membres. Je suis sûr que ce sera un sujet que certains de nos membres les plus importants aborderont. Ils vont se réunir et en discuter. »

Parmi les experts Oracle, nos confrères d'Inforworld ont rencontré Shirish Ojha, senior DBA Oracle pour Logicworks, un fournisseur de services en ligne de type cloud. Il était bien sûr informé des problèmes du SCN, et notamment du bug  de la numérotation. Il reconnaît que quelques environnements Oracle sont susceptibles de rencontrer le problème, et que les conséquences peuvent être graves. « S'il y a un bond spectaculaire dans les SCN en raison d'un bug Oracle, il y a une probabilité minimale de rupture si ce nombre devient anormalement  élevé », a déclaré M. Ojha, qui a obtenu le très convoité titre d'Oracle Certified Master. « Si cela se produit pendant des transactions intensives sur une grande architecture interconnectée, cela va rendre toutes les bases de données interconnectées Oracle inutiles dans un laps de temps très court. »

M. Ojha poursuit : « Si cela se produit, même si la probabilité reste faible, le potentiel de perte [financière] ... est très élevé. » Par définition, dit-il, le problème peut potentiellement uniquement affecter tous les grands clients d'Oracle. Mais « une fois la limite SCN atteinte, il n'existe pas d'autre moyen de sortir du problème, que de fermer toutes les bases de données et de les reconstruire à partir de zéro. »

[[page]]

Anton Nielsen, le président C2 Consulting et expert Oracle, a évalué le risque potentiel d'attaque malveillante utilisant un SCN élevé: « En théorie, l'attaque SCN élevée est similaire à une attaque DoS de deux manières significatives : Il peut mettre un système à genoux, le rendant inutilisable pour une période de temps significative, et il peut être accompli par un utilisateur avec des autorisations limitées. Alors qu'une attaque DoS peut être perpétrée par n'importe qui avec un accès réseau à un serveur web, la modification du SCN nécessite un accès à la base de données via un nom d'utilisateur et un mot de passe. »

La réaction d'Oracle

Lorsque nos confrères d'Infoworld ont contacté Oracle au sujet du SCN, Mark Townsend, vice-président en charge des bases de données, a demandé un peu de temps pour évaluer le problème. « La façon dont vous mettez ces [questions] ensembles ne ressemble à rien de ce que nous avons vu ... nous avons besoin de comprendre ce que vous avez fait pour élever de plusieurs milliards le SCN. »

Après de nombreuse discussions et l'échange de données techniques, Oracle a reconnu qu'il y avait plusieurs façons d'augmenter le SCN à volonté. Se référant à une de ces méthodes, M. Townsend a déclaré : « C'est une situation irrégulière, un paramètre caché, il n'a jamais été prévu que les clients le découvrent et l'utilisent. » Toutefois, nos confrères ont souligné qu'il y avait plusieurs autres méthodes qui pourraient être utilisées. Elles ont bien sûr été détaillées à Oracle.

Des correctifs disponibles depuis janvier 2012

Pour corriger ces vulnérabilités, Oracle a publié une série de patchs présents dans sa mise à jour de janvier (Oracle Critical Patch). Ces correctifs bloquent les différentes méthodes qui permettent d'augmenter artificiellement la numérotation du SCN et mettent en oeuvre une nouvelle méthode de protection, ou «l'inoculation», comme le dit M. Townsend, pour les bases de données Oracle.

Nos collègues n'ont pas eu le temps de tester exhaustivement ces correctifs, ils ne savent donc pas encore ce que cache le terme «inoculation». En fait, sans de nombreux tests, il est pour l'instant impossible de fournir plus de détails sur les moyens de bloquer la hausse de la numérotation du SCN lorsque plusieurs bases de données sont interconnectées.

Ces correctifs sont seulement disponibles pour les récentes versions du SGBD de l'éditeur : Oracle 11g 11.1.0.7, 11.2.0.2, et 11.2.0.3, ainsi qu'Oracle 10g 10.1.0.5, 10.2.0.3, 10.2.0.4 et 10.2.0.5. Les versions plus anciennes continueront d'être affectées. Étant donné le grand nombre d'installations de licences Oracle 11.2.0.2.0 et 10.1.0.5, une importante base installée restera vulnérable.

Les prochaines étapes

La prochaine étape pour les administrateurs  de SGBD Oracle est d'inspecter les valeurs SCN de leurs bases de données. Par la suite, l'application du patch de sauvegarde live est cruciale, comme le sont les patchs de suivi qui traitent de la capacité d'augmenter arbitrairement la valeur du SCN via les commandes d'administration. Cependant, puisque des correctifs existent pour les nouvelles versions de la base de données, il doit certainement y avoir un moyen de moderniser les anciennes bases de données pour régler le problème.

Il est également essentiel que les administrateurs DBA évitent soigneusement de connecter des serveurs Oracle non patchés à d'autres bases de données Oracle au sein de leur infrastructure. Ce sera un vrai défi pour toutes les entreprises qui utilisent des versions différentes d'Oracle DBA, mais c'est indispensable pour éviter une corruption du SCN.

Tous les commentaires et les témoignages des spécialistes de la base de données d'Oracle sont les bienvenus.