Oracle : Zoller « De quoi ? »
Un rapport de Red Database Security sur les derniers correctifs cumulatifs Oracle donne un bref aperçu de la somme des problèmes traités. « Déjà ! » s'écrient certains. « Enfin » rétorque Thierry Zoller qui, au fil d'une contribution sur la liste Full Disclosure, retourne sèchement une petite liste assassine : Oracle Bug 5882923 : 875 days Oracle Bug 5883603 : 889 days Oracle Bug 5883621 : 874 days ago Oracle Bug 5802023 : 190 days Les usagers du SGBD auront compris, il s'agit là du temps de correction après découverte de chaque faille. Il est fort peu probable que les presque 3 années écoulées avant publication d'une rustine aient été consacrées aux tests de non-régression. Ou alors, il faut plaindre les développeurs de Larry Ellison. Que peut donc invoquer l'éditeur à propos d'un tel retard ? La faible dangerosité du défaut constaté ? Argument irrecevable, car ce n'est certes pas au fournisseur de savoir ce qui représente une menace pour ses propres clients. Juge et partie ne peuvent plaider d'une même voix. Que reste-t-il alors comme excuse plausible ? Un « oubli » ou une erreur humaine ? De la part d'un spécialiste de la gestion de base de données, voilà qui est difficile à admettre. Ou alors avec beaucoup de mauvais esprit et des arguments spécieux :« Nos index étaient corrompus, le patron du Response Team persiste à utiliser dBase III+ ». La volonté émise de la part d'un Organisme d'Etat de voir certains défauts laissés sans colmatage, pour que soit satisfait l'Intérêt Supérieur de la Nation et de ses Serviteurs ? Chimères de journaliste ! D'ailleurs, on ignore jusqu'au mot d'ordinateur et de hacking noir chez ces gens là. Ce serait s'abaisser à employer des méthodes amorales. Reste à la rigueur une explication : conserver un stock de trous en tous genres pour que, le jour venu, les usagers émerveillés par ces rutines à fragmentation puissent se dire « Mazette, çà, c'est du beau patch, élevé sous la mère, dodu à souhait et garanti 3 ans en herbage libre... y savent travailler chez Oracle ». Non, franchement, çà ne tient pas debout. Serait-ce alors pour justifier de la raison sociale de l'entreprise ? « On vous l'assure, dans 3 ans, nous corrigerons un bug que l'on baptisera 5882923 ! ». Même pas, car il y a trois ans, Oracle était « unbreakable », foi de pythonisse. Quand toutes les hypothèses ont été évoquées, il reste l'impensable. A savoir un mécanisme de gestion des bugs chez Oracle qui tient à la fois du Tri à Bulles et de la Théorie du Chaos. Et pour l'un des principaux vecteurs de recherche en matière de récupération d'information, c'est là un éclairage assez flatteur. Il se pourrait également qu'un passionné des masques de saisie et des variables ne soit tombé sur cet « Highly Critical Monthly Oracle Security Alert Bulletin » réutilisable ad vitam aeternam publié sur le blog de l'OSVDB.
