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.