Discussion :

[Waldar]

Voici notamment ce qu'il est possible de faire avec cette faille :
http://blog.red-database-security.co...lem-published/

[eprost]

Par avance, toutes mes excuses si le ton de ce post est parfois un peu "abrupt", je n'ai pas trop de temps à consacrer à la formulation...

Je ne sais plus exactement mais c'est un truc du style ne effet. Si tu as les droits CREATE VIEW même sans avoir les droits UPDATE tu peux mettre une table à jour... ce qui est "facheux"

Tout le monde en convient, moi le premier.

Peu importe, le piratage vient souvent de l'interieur et j'estime qu'autoriser la mise à jour du table alors que t'es sensé ne pouvoir que la consulter c'est une faille

Très vrai.

C'est d'ailleurs pourquoi les PC des développeurs sont sur un réseau séparé du réseau de la production, c'est pourquoi les données récupérées de la production sont "blanchies" avant d'être importées sur les bases de recette ou de test, c'est également pour cette raison que l'on met en place de l'audit à tous les niveaux (Oracle, OS, réseau, ...), c'est pourquoi les mots de passe en production sont différents de ceux utilisés sur les autres plates-formes, et c'est pourquoi on a obligation de créer différents comptes avec différents droits (= GRANT) dans le SGDB en fonction des besoins de chacun, etc.

Dans cette affaire, que Oracle possède plus ou moins de failles qu'un autre moteur est sans intérêt, je considère que c'est un critère de choix très marginal.

Il y a d'autres problématiques bien plus profondes et bien plus importantes à considérer avant de pondérer le choix du moteur par le nombre de failles. A quoi me sert d'avoir un moteur hyper blindé si les équipes de développement font leurs tests sur des données récupérées depuis le système en production sans avoir été blanchies ? A quoi me sert d'avoir un moteur hyper blindé si le DBA a un casier judiciaire de 30 pages ? J'exagère ? Vous donneriez les clefs de votre logement sans vous poser de questions à quelqu'un qui a été condamné pour cambriolage ? et quand c'est les mots de passe qui donnent accès aux données banquaires de vos clients et à tout l'historique de leurs commandes, données qui peuvent être revendues à votre concurrent ?

Pour une raison que j'ignore, on fait un focus sur cette problématique de failles alors que c'est clairement et absolument un problème d'architecture du Système d'Information, de procédures, et d'organisation de l'entreprise. En se focalisant sur le nombre de failles du moteur X par rapport au moteur Y, on oublie des problématiques qui sont d'une autre importance (et c'est parfois bien confortable, je l'admets, de pouvoir "oublier" ce genre de choses).

Je ne te parle pas de bonnes pratiques en terme de sécurité mais bien de failles. Et pouvoir écrire dans une table sans avoir de privilège UPDATE c'est une faille

Oui c'est une faille, cela ne fait absolument aucun doute.

Mais je persiste : cette faille est effective ou non en fonction de l'architecture et donc des bonnes pratiques.

Exemple de bonne pratique : le compte Oracle (SQL Server, DB2, ...) qui est utilisé pour modifier le schéma doit être différent du compte qui est utilisé pour exploiter les données depuis le code applicatif. En d'autres termes, on a un compte dédié aux opérations telles que CREATE XXX, et (au moins) un compte applicatif auquel on ne donne que le droit SELECT.

Pour faire un parallèle avec le monde des systèmes d'exploitation, c'est comme de dire que l'on a un compte d'administration et un compte utilisateur "standard" (au moins - idéalement, il faut évidemment un compte par utilisateur physique différent)

Il ne viendrait l'idée à personne de dire "je vais comparer Windows et Linux sur le thème de la sécurité en considérant que tout le monde et tous les service (ou "démons") travaillent avec un seul et unique compte administrateur (ou root)", n'est-ce pas ?

Pourquoi cette évidence absolue, qui est une bonne pratique et que l'on ne peut pas raisonnablement remettre en cause sauf à avoir un comportement criminel, doit-elle être ignorée quand on parle de SGBD ?

Note : sans être un expert judiciaire, je parle de "comportement criminel" au sens strict du terme car je rappelle qu'il est puni par la loi dans certains pays de ne pas mettre en place les mécanismes adéquats afin, par exemple, de protéger le Système d'Information et de laisser ainsi "fuiter" des informations à caractère personnel ou confidentiel. Mine de rien, on se rend compte que savoir s'il y a 200 failles sur un moteur et 210 sur un autre moteur est une question très très mineure quand on aura à s'expliquer, sans aller jusqu'au judiciaire, dans un différend commercial avec un client ou face à des auditeurs envoyés par un client mécontent de s'être fait piraté ses données : il alors hautement indispensable d'avoir appliqué les bonnes pratiques, ou d'avoir un excellent argumentaire pour expliquer pourquoi elles n'ont pas été appliquées.

Quiz, pour égayer la discussion : combien de failles ne sont pas rendues publiques par les éditeurs ? étant donne que personne n'en sait rien, comment fait-on pour comparer deux moteurs (propriétaires) ?

Donc je persiste, une faille est un défaut d'implémentation mais ce qui importe n'est pas son existence, c'est le caractère effectif de la faille dans l'architecture cible, dans le respect des bonnes pratiques, sinon ce n'est même la peine de chercher plus loin puisque l'architecture sera pleine de trous.

Moi je pense que c'est à l'éditeur d'éviter les failles

Heu ... tu voudras bien excuser la rugosité de mon analyse, n'y vois aucune méchanceté, mais au final, tu demandes à l'éditeur d'atteindre un objectif impossible, c.à.d le "zéro bug". Dis autrement, cela s'appelle une lettre au Père Noël :-)

Plus sérieusement : cela ne peut pas être une solution.

... et pas au client de monter des solutions plus ou moins contraignantes pour s'en prémunir. Si la solution c'est interdire le CREATE VIEW alors c'est pas une solution, c'est juste la suppression d'une fonctionnalité

Globalement, c'est au responsable du système de construire ou faire construire une architecture où la sécurité est pensée dès le début. Et oui, dans l'absolu, cette solution sera contraignante, c'est son but que d'interdire ce qui n'est pas autorisé.

Et dans le cas particulier du CREATE VIEW, ALTER TABLE, ..., il faut absolument les restreindre aux quelques personnes qui sont habilitées à faire évoluer le schéma des bases. Cela fait partie des bonnes pratiques ("least privilege", + audit, évidemment), et à mon sens, cela n'est pas négociable : sauf cas d'exception, le ou les comptes utilisés par l'application n'ont aucune bonne raison d'avoir le droit de faire un CREATE VIEW. Et si ce droit est donné, alors il est audité (et dans le cas d'Oracle, on peut aussi songer à utiliser les mécanismes d'attribution de droit un package qui encapsule la chose - pour ceux qui ne connaissent pas, c'est un peu comme le "sudo" de Unix / Linux ou le "exécuter en tant qu'Administrateur" de Windows).

Cordialement (et, encore une fois, je présente mes excuses si la formulation de mon post est parfois un peu abrupte).

[Vincent Rogier]

Pour reprendre l'analyse de Pete Finningan, dont l'expertise en termes de sécurité Oracle est reconnue, les deux points majeurs de la sécurisation d'un environnement Oracle sont :

- restreindre les accès physiques et les protéger (notamment le listener)
- restreindre au max les privilèges utilisateurs. Par exemple, des milliers de privilèges sont public dans une base oracle par défaut, c'est tout de même hallucinant.

J'avais passé un peu de temps avec Pete l'été dernier et j'avais enregistré notre conversation sur le domaine et ou il avait exprimé son avis sur la sécurisation d'un environnement Oracle. Je n'ai malheureusement toujours pas retranscrit cette " interview" que je devais publier sur dvp .

Faudrait donc que je m'y mettes.

[eprost]

Pour reprendre l'analyse de Pete Finningan, dont l'expertise en termes de sécurité Oracle est reconnue, les deux points majeurs de la sécurisation d'un environnement Oracle sont :

- restreindre les accès physiques et les protéger (notamment le listener)
- restreindre au max les privilèges utilisateurs. Par exemple, des milliers de privilèges sont public dans une base oracle par défaut, c'est tout de même hallucinant.

...

De votre expérience, est-ce différent sur d'autres moteurs ?

[Vincent Rogier]

De votre expérience, est-ce différent sur d'autres moteurs ?

ben, mon expérience des autres moteurs est plus que limité... Je suis un oraclien convaincu....

[orafrance]

Pour une raison que j'ignore, on fait un focus sur cette problématique de failles alors que c'est clairement et absolument un problème d'architecture du Système d'Information, de procédures, et d'organisation de l'entreprise. En se focalisant sur le nombre de failles du moteur X par rapport au moteur Y, on oublie des problématiques qui sont d'une autre importance (et c'est parfois bien confortable, je l'admets, de pouvoir "oublier" ce genre de choses).

Pour une raison très simple... Oracle n'a jamais eu autant de concurrence qu'aujourd'hui et la sécurité est un critère suffisamment sensible pour qu'il fasse la différence. Des développeurs qui doivent accéder en lecture aux données de prod ça existe aussi. Et si le simple fait d'avoir se droit suffit à ce qu'ils puissent modifier les données, moi ça me pose problème

Exemple de bonne pratique : le compte Oracle (SQL Server, DB2, ...) qui est utilisé pour modifier le schéma doit être différent du compte qui est utilisé pour exploiter les données depuis le code applicatif. En d'autres termes, on a un compte dédié aux opérations telles que CREATE XXX, et (au moins) un compte applicatif auquel on ne donne que le droit SELECT.

Si seulement le monde pouvait être parfait... malheureusement, il n'en est rien. On a déjà du mal à faire comprendre que chaque dév doit avoir son compte et qu'on doit pas donner ses connexions à quelqu'un d'autre, alors plusieurs comptes pour un dév... bah, j'ai jamais vu

Il ne viendrait l'idée à personne de dire "je vais comparer Windows et Linux sur le thème de la sécurité en considérant que tout le monde et tous les service (ou "démons") travaillent avec un seul et unique compte administrateur (ou root)", n'est-ce pas ?

C'est vrai... en revanche tu peux comparer la simplicité de la mise en place de la sécurité sous Linux vs Windows... et là tu as des points de comparaison tout ce qu'il y a d'objectifs. Windows sans controleur de domaine c'est une passoire ou alors une infamie à configurer. Windows ne permet pas d'avoir un profile différent selon les besoins, ce qui pose de gros soucis de scripting. Enfin... on va pas rentrer dans le débat... on a déjà assez à faire avec Oracle

Quiz, pour égayer la discussion : combien de failles ne sont pas rendues publiques par les éditeurs ? étant donne que personne n'en sait rien, comment fait-on pour comparer deux moteurs (propriétaires) ?

Aucun éditeur n'est transparent quant aux failles C'est pour ça que des entreprises se font une spécialité de trouver ses failles. Le nombre de failles n'a aucune importance dans l'absolu, c'est le nombre de failles exploitables qui pose problème. Et force est de constater qu'Oracle est le pire SGBD sur le marché dans ce domaine (un exemple tout bête : UTL_FILE_DIR qui imposait d'avoir une collaboration très étroite entre DBA et admin système et imposait des contraintes à l'admin système... ce qui est inacceptable de mon point de vue).

Heu ... tu voudras bien excuser la rugosité de mon analyse, n'y vois aucune méchanceté, mais au final, tu demandes à l'éditeur d'atteindre un objectif impossible, c.à.d le "zéro bug". Dis autrement, cela s'appelle une lettre au Père Noël :-)

C'est pas parce qu'on peut pas atteindre le 0-bug qu'on doit accepter que des bugs persistent depuis plus de 10 ans. Moi j'appelle ça tout simplement de l'incompétence. Au prix de la licence, j'estime que le support fait un travail très médiocre sur la sécurité alors même qu'on leur met sous le nez des failles énorme. Vivre sur ses acquis ça ne dure qu un temps.

Si toi tu acceptes qu'un éditeur ne cherche pas à améliorer la qualité de son produit, moi c'est pas le cas

Et dans le cas particulier du CREATE VIEW, ALTER TABLE, ..., il faut absolument les restreindre aux quelques personnes qui sont habilitées à faire évoluer le schéma des bases.

Malheureusement, ce n'est qu'un exemple parmi des centaines d'autres et c'est pas toujours facile de contourner le problème

et, encore une fois, je présente mes excuses si la formulation de mon post est parfois un peu abrupte

ne t'inquiète pas pour le ton de tes réponses. C'est un débat, et comme tout débat de passionnés c'est le fond qui doit primer sur la forme

[orafrance]

De votre expérience, est-ce différent sur d'autres moteurs ?

Oui, Microsoft est bien meilleur notamment dans la correction des failles connues. Et évidemment, le manque d'ouverture du SGBD et la parfaite maitrise de l'OS (pour cause ) leur permet de mieux appréhender les problématiques de sécurité. En gros, si l'OS est sécurisé, les bases le seront... ce qui n'est pas le cas d'Oracle qui impose une double sécurisation. Mais Oracle à d'autres avantages même si depuis que je connais SQL Server je suis beaucoup plus critique à leur égard

Pour info : http://www.databasesecurity.com/dbsec/comparison.pdf

The conclusion is clear – if security robustness and a high degree of assurance are
concerns when looking to purchase database server software – given these results one
should not be looking at Oracle as a serious contender.

Note importante : c'est le premier lien que j'ai trouvé, j'ai pas vérifier l'indépendance de la source

Voila néanmoins qui tend à confirmer cette "analyse" : http://securite.reseaux-telecoms.net...use-14868.html

- restreindre les accès physiques et les protéger (notamment le listener)

Tiens, ça me fait penser à une autre faille : est-ce que les communications SQL*Net peuvent enfin être crypter ? Parce que fut un temps où il suffisait de sniffer le réseau pour avoir les mots de passe en clair

Ce qui me fait penser à autre chose par rapport à ce que disait eprost. eprost, fait une recherche sur le hack des mots de passe sous Oracle... tu vas vite comprendre que n'importe qui pouvant accéder à une base peut cracker le password en quelques minutes. Je ne voudrais pas dire de bêtise mais de mémoire on a cracker un password de 8 caractères en moins de 30 minutes avec un collégue Ca prend même pas 2 minutes avec 6 caractères... c'était à te dégouter de perdre du temps à sécuriser la base

Mais encore une fois, pour moi le problème n'est pas temps la sécurité sur Oracle que le manque de réactivité du support pour corriger leurs failles . Et puis c'est pas non plus dramatique, certaines entreprises sécurisent le réseau par ailleurs comme tu l'as souligné... mais comme c'est un débat avantages et inconvénients... on peut quand même pas passer ce problème sous silence

[wizdom]

Tiens, ça me fait penser à une autre faille : est-ce que les communications SQL*Net peuvent enfin être crypter ? Parce que fut un temps où il suffisait de sniffer le réseau pour avoir les mots de passe en clair

Je ne comprends pas bien le sens du "enfin" ? Il a toujours été possible d'encrypter le flux SQL*Net (au moins depuis la version 8). Simplement, cela n'est pas activé par défaut. Ce qui est bien normal vu qu'il y a obligatoirement un paramétrage à mettre en oeuvre. Exactement comme un serveur web qui fonctionnerait en http à l'installation et pour lequel on doit faire quelques paramétrages pour utiliser du https.

Je dirais même que c'est un des avantages d'Oracle. Les possibilités de sécurisation du flux sont vraiment intéressantes (voir mon post page précédente : http://www.developpez.net/forums/d61...e/#post4034778 )

Un autre exemple de ce qu'il est possible de faire à ce niveau :

http://www.aud-it.ch/Oracle_Securite_Trivadis.pdf

[Vincent Rogier]

Je ne comprends pas bien le sens du "enfin" ? Il a toujours été possible d'encrypter le flux SQL*Net (au moins depuis la version 8).

Effectivement, c'est le cas

Fred, je te recommande la lecture du "Net Services Administrator’s Guide" et du "Oracle Database Advanced Security Administrator's"

[orafrance]

Il semblerait (à confirmer parce qu'on m'en a parlé il y a un bout de temps maintenant) que le cryptage SQL*Net n'affectait que les données et pas la chaine de connexion. En clair, le password restait en clair malgré les mesures de cryptage SQL*Net.

Sinon, il y a quand même une option excellente c'est la possibilité de limiter les lignes ou colonnes visibles par l'utilisateur en fonction du contexte... le VPD c'est très intéressant

[wizdom]

Ca doit avoir un rapport avec ceci je pense ?

http://www.petefinnigan.com/rambling...clear_text.htm

(l'article date de 2004)

Le résumé pour faire court : "Depuis la version 7.3 (1992 tout de même), le mot de passe est encrypté. Cependant il existe un problème lorsqu'on change le mot de passe d'un user Oracle avec la commande Alter User. Il est donc préconisé d'utiliser la commande password."

C'est toujours bon à savoir ! Même si on ne change pas les mots de passe des schémas Oracle tous les matins. Enfin, ici, l'auteur ne parle pas d'encryption SSL entre le client et le serveur. J'ai l'impression qu'il s'agit d'une session SQL*Net classique ?

[voran]

Ca va plus loin, Oracle n'est pas officiellement certifié(=supporté) sur d'autres plateformes de virtualisation que celle d'Oracle.
Le demandeur du support devra prouver lui même que son soucis n'est pas lié à virtualisation (=reproduire le cas sur une plateforme native).

A classer dans la rubrique "inconvénients d'Oracle"...

ça ce n'est pas une spécificité ORACLE. Notre support microsoft nous a sorti la même chose.

[voran]

[*]Pas mauvais sur le marché de la haute dispo, gestion des clusters, ..[*]...[/list]

SQL Server est bien meilleur... je dirais que c'est plutôt un inconvénient pour Oracle en fait

ça ! ça mérite des précisions!
Par quels moyens sql server est il meilleur que ORACLE RAC ?
Ce n'est pas que je ne le crois pas, c'est que je cherche en vain des info sur la config d'un sql server en cluster actif-actif. Un moyen de faire la même chose que TAF avec ORACLE.
et ce même avec sql server 2008 !
J'attend ...

[orafrance]

La haute dispo n'impose pas d'avoir deux noeuds actifs. Le RAC est, selon moi, plutôt destiné à partager la charge entre plusieurs serveurs, la haute dispo étant une fonctionnalité évidemment incluse de fait au RAC mais ce n'est pas l'objectif premier.

La HA c'est plutôt Dataguard pour Oracle et le mirroring sous SQL Server et dans là, force est de constater que le mirroring est non seulement plus simple à mettre en oeuvre et à maintenir mais qu'il est aussi simple à monitorer quand Oracle impose d'avoir Grid Control.

RAC pour le partage de charge et Dataguard/Mirroring pour la récupération de panne.

Ceci étant dit, le RAC c'est vraiment génial mais bien trop cher pour n'en faire qu'une "simple" solution HA.

Sinon, l'actif-actif n'est pas possible mais tu peux faire de l'actif-passif croisé... et là ça devient nettement plus complexe que le RAC pour le coup

[voran]

La haute dispo n'impose pas d'avoir deux noeuds actifs.

Mais oracle le propose et c'est là un réel avantage par rapport à ses concurrents.

La HA c'est plutôt Dataguard pour Oracle et le mirroring sous SQL Server

Désolé, l'offre HA ORACLE est plus complète que ça. C'est comme ça

et là, force est de constater que le mirroring est non seulement plus simple à mettre en oeuvre et à maintenir mais qu'il est aussi simple à monitorer

J'en suis pas (encore ? ) mort

quand Oracle impose d'avoir Grid Control.

Tu veux dire implicitement ?
pourquoi ? Le grid control ça sent le camebert ?
perso c'est l'inverse, je suis toujours dérouté avec les outils sql server comme quoi, quand on est habitué à une GUI ...

Ceci étant dit, le RAC c'est vraiment génial mais bien trop cher pour n'en faire qu'une "simple" solution HA.

par rapport aux fonctionnalité offert, ça se discute, surtout que RAC fait partie de la licence oracle standard.

[orafrance]

Mais oracle le propose et c'est là un réel avantage par rapport à ses concurrents.

Oui mais à quel prix ?

Tu veux dire implicitement ?
pourquoi ? Le grid control ça sent le camebert ?

Non, mais c'est aussi bien que cher... c'est dire comme c'est bien

perso c'est l'inverse, je suis toujours dérouté avec les outils sql server comme quoi, quand on est habitué à une GUI ...

Un mauvais GUI vaut mieux que 2 outils (SQL*Plus et DGMGRL) en ligne de commande... sinon, j'suis d'accord, ne serait-ce que pour les perfs, pour le coup le GUI MS pue le camembert

par rapport aux fonctionnalité offert, ça se discute, surtout que RAC fait partie de la licence oracle standard.

t'es sûr ? Pourtant c'est une option de la version Entreprise et c'est pas loin des 15k€/CPU Au passage, Dataguard est également payant quand le mirrorring de SQL Server est inclut

[fatsora]

Oui mais à quel prix ?


Un mauvais GUI vaut mieux que 2 outils (SQL*Plus et DGMGRL) en ligne de commande... sinon, j'suis d'accord, ne serait-ce que pour les perfs, pour le coup le GUI MS pue le camembert

????

Je prefère des outlis lignes de commande qui fonctionnent que des graphiquent qui plantent

t'es sûr ? Pourtant c'est une option de la version Entreprise et c'est pas loin des 15k€/CPU Au passage, Dataguard est également payant quand le mirrorring de SQL Server est inclut

cf Doc ID: Note:271886.1 le RAC existe bien en Standard !!!

[orafrance]

????

Je prefère des outlis lignes de commande qui fonctionnent que des graphiquent qui plantent

Les graphismes fonctionnent bien sous SQL mais c'est la lecture qui n'est pas des plus... évidentes

[voran]

Mais oracle le propose et c'est là un réel avantage par rapport à ses concurrents.

Oui mais à quel prix ?

A quel prix ? Moins cher que tu ne le pense. il faut juste s'adresser aux professionnels partenaires.
En tant que gold partenaire microsoft et partenaire certifié oracle, nous proposons des licences au clients qui le souhaitent (ce n'est pas notre activité principale). Le cout des licences oracle est sensiblement le même que pour sql server. Tous les ans, il faut renégocier c'est sûr mais c'est parfois le cial de microsoft qui pose problème.

Un mauvais GUI vaut mieux que 2 outils (SQL*Plus et DGMGRL) en ligne de commande... sinon, j'suis d'accord, ne serait-ce que pour les perfs, pour le coup le GUI MS pue le camembert

Et oui, entre l'informatique et la bureautique, il faut choisir
Nan, je déconne Chacun sa méthode, pourvu qu'elle soit efficace

par rapport aux fonctionnalité offert, ça se discute, surtout que RAC fait partie de la licence oracle standard.

t'es sûr ? Pourtant c'est une option de la version Entreprise et c'est pas loin des 15k€/CPU Au passage, Dataguard est également payant quand le mirrorring de SQL Server est inclut

Sur ce coup là, tu m'as l'air très mal renseigné.
c'est même indiqué ici :http://www.oracle.com/database/product_editions.html

[orafrance]

Le cout des licences oracle est sensiblement le même que pour sql server.

La base oui, mais si tu commences à taper dans les options, je crains qu'Oracle devienne plus cher

Et oui, entre l'informatique et la bureautique, il faut choisir
Nan, je déconne Chacun sa méthode, pourvu qu'elle soit efficace

je passe par les lignes de commandes quasi tout le temps mais concernant Dataguard c'est vite fastidieux et un petit GUI ne ferait pas de mal, visiblement celui du grid est bien fichu en plus

Sur ce coup là, tu m'as l'air très mal renseigné.
c'est même indiqué ici :http://www.oracle.com/database/product_editions.html

En effet, en fait je me suis arrêté à la page de Oracle Store qui l'indique en option pour la version Entreprise En fait, c'est en option pour l'entreprise mais inclus en standard... je ne vais pas essayer de comprendre