Discussion :

[Laurent_du_78]

Pour ma part, j'ai participé à une présentation de RAT : Real Application Testing.
Je vous la faire court :
- Capture les opérations réalisés sur la base SELECT, INSERT et UPDATE sauf ceux en DIRECT PATH (sql*loader, INSERT /* Append */
- Application de ces opérations sur une autre base.

Inconvénients :
- vous ne pouvez modifier votre modèle de données sous peine d'avoir quelques erreurs sur les flux capturés.
- option payante, à laquelle il vaut mieux aussi prendre "SQL Performance Analyser" qui vous permettra en quelques clic de comparer les performances des requêtes à partir d'AWR. Zut, il faut aussi l'option payante "Diagnostic pack"

Avantage :
- Mais on peut tester une nouvelle version d'Oracle ou un patch. On va donc payer pour acheter un outil pour tester un patch Oracle

Pour conclure,
- cela peut être un outil complémentaire de test
- il peut aussi permettre de tester des paramétrages de base différents

Pour la 11gR2 (ou R1) en dehors de la date de fin de support :
- partitionning (option payante) :
- compression OLTP, interressant (option payante)
- le curseur adaptatif
- les caches de résultats
- ASM
- Cryptage de tablaspace (option payante)
- ...

[laurentschneider]

and the Senior DBA throws out the CD and waits for Release 2

Ouais, c'est bien ce qui est toujours arrivé, d'ailleurs Oracle a annoncé qu'il n'y aurait plus de patchset pour la release 1 (et il n'y a eu qu'un seul patchset en tout)



Bon j'espère une sortie prochaine de 11.2 sur les autres plateformes/architectures

[Gordon Fowler]

Oracle 11g R2 : une faille permet de prendre le contrôle total du SGBD
L'implémentation de Java dans la base de données serait en cause


La base de donnée Oracle 11g R2 possèderait une faille de sécurité importante qui permettrait à un utilisateur mal intentionné d'en prendre le contrôle complet et total ("complete control over the database").

C'est en tout cas ce qu'affirme David Litchfield, chercheur renommé pour le NGS Consulting lors du colloque sur la sécurité informatique du Black Hat.

Démonstration à l'appui, Litchfield a ainsi montré à l'assistance comment un utilisateur lambda pouvait s'approprier des droits d'administration supérieurs.
Il explique par ailleurs que la faille viendrait de la manière dont Java a été implémenté dans Oracle 11g Release 2.

Jusqu'à ce que Oracle la colmate, David Litchfield recommande donc aux administrateurs du SGBD de limiter l'accès et l'exécution publics de certaines fonctions en Java.

Pour faciliter la tache de Larry Ellisson, le pDG d'Oracle, avec qui il entretient visiblement des relations "rock n' roll" (vo "rocky relations"), le chercheur publiera prochainement un white paper de son exploit.

Néanmoins, ce vétéran de la recherche en sécurité (et un des plus reconnus) trouve que la sécurité du SGBD d'Oracle s'est nettement améliorée par rapport aux versions précédentes.

Ce qui ne l'empêche pas d'affirmer dans le même temps que le géant du logiciel se repose trop sur les outils de sécurité au lieu d'intégrer ces problématiques dès la phase de conception de ses produits.

Ce n'est visiblement pas demain la veille que les deux seniors deviendront les meilleurs amis du monde IT.


Source : Conférence lors du Black Hat

Et vous ?

Pensez-vous comme David Litchfield qu'Oracle ne prend pas assez en compte la sécurité dans la conception de ses offres ?

Comment régissez-vous à cette annonce de cet exploit "zero-day" : indifférence, préoccupation, étonnement ?

[laurentschneider]

bon, la faille il faut la trouver. mais c'est vrai que suivant les failles que tu trouves, Oracle a parfois une reaction d'autruche.

Bon, la, le controle total, c'est grave, mieux vaut virer Java alors

[orafrance]

Pensez-vous comme David Litchfield qu'Oracle ne prend pas assez en compte la sécurité dans la conception de ses offres ?

Sans aucun doute, ils restent encore beaucoup de failles à colmater au sein du SGBD lui-même et le temps de réaction d'Oracle est bien trop long eu égard à la criticité des données qu'ils peuvent compter parmi leur leurs plus gros clients.

Comment régissez-vous à cette annonce de cet exploit "zero-day" : indifférence, préoccupation, étonnement ?

Indifférence, en effet, les utilisateurs lambda n'ont pas à avoir des accès en exécution sur les packages system, de fait, la faille n'est sensé pas être utilisable. Cela n'impacte que les bases où le DBA a une politique laxiste de la sécurité.

[orafrance]

Bon, la, le controle total, c'est grave, mieux vaut virer Java alors

Ca a toujours été le cas du reste depuis qu'Oracle à intégrer le java, ils vont de problème en problème

[scheu]

Sinon à part ça certains ont-il déjà upgradé certaines de leurs bases en 11gR2 ?
Pas trop de soucis ? Un patch 11.2.0.2 est-il bientôt prévu ?

[voran]

Sans aucun doute, ils restent encore beaucoup de failles à colmater au sein du SGBD lui-même

Ha ? Lesquelles ?

et le temps de réaction d'Oracle est bien trop long

Des exemples peut-être ?

[voran]

Ca a toujours été le cas du reste depuis qu'Oracle à intégrer le java, ils vont de problème en problème

Enfin, là il est question du package Java non ?

[voran]

Pensez-vous comme David Litchfield qu'Oracle ne prend pas assez en compte la sécurité dans la conception de ses offres ?

Absolument pas !
Il s'agit d'un exploit peu crédible dans la mesure où il ne concerne que les bases dont l'admin n'a pas respecté les consignes de sécurités élémentaires !
Cela démontre surtout les motivations de M. Litchfield ainsi que le niveau de pertinance de ses articles.

Comment régissez-vous à cette annonce de cet exploit "zero-day" : indifférence, préoccupation, étonnement ?

Indidérence donc

[Pomalaix]

Cela n'impacte que les bases où le DBA a une politique laxiste de la sécurité.

Et malheureusement, ça représente un pourcentage assez impressionnant !
Quand on voit des bases de prod avec SYSTEM/MANAGER, ou des bases de test, copies conformes de la prod du point de vue des données, où le mot de passe est identique au nom du compte systématiquement (SCOTT/SCOTT)...

[voran]

Et malheureusement, ça représente un pourcentage assez impressionnant !
Quand on voit des bases de prod avec SYSTEM/MANAGER, ou des bases de test, copies conformes de la prod du point de vue des données, où le mot de passe est identique au nom du compte systématiquement (SCOTT/SCOTT)...

encore du jamais vu en ce qui me concerne!

[Invité]

Et malheureusement, ça représente un pourcentage assez impressionnant !
Quand on voit des bases de prod avec SYSTEM/MANAGER, ou des bases de test, copies conformes de la prod du point de vue des données, où le mot de passe est identique au nom du compte systématiquement (SCOTT/SCOTT)...

Rencontré moult fois...

[voran]

...

[voran]

Rencontré moult fois...

Vraiment surprenant !
Je serait curieux de savoir combien de fois et chez qui ...

Dans mon cas il s'agit d'entreprise allant de 1000 à 170000 employés dans des domaines variés (banques, grande distribution, services, fonction public...)

[Invité]

je ne rentrerais pas dans les détails mais c'était une solution logicielle pour le secteur public.
Et pour se connecter à la machine de la bd, il y avait une sécurité par RDP à deux ou trois niveaux...

Sinon, il y a les petits développements qui perdurent et arrivent en prod avec une bd installée par un non dba.

[orafrance]

Ha ? Lesquelles ?

Des exemples peut-être ?

par exemple : http://seclists.org/fulldisclosure/2006/Apr/176

Mettre à jour des tables alors que t'es pas sensé avoir les droits c'est facheux je trouve

Quand on voit des bases de prod avec SYSTEM/MANAGER, ou des bases de test, copies conformes de la prod du point de vue des données, où le mot de passe est identique au nom du compte systématiquement (SCOTT/SCOTT)...

Sans aller jusque là, je ne compte plus les bases de prod copiée en dév ou tout le monde à un accès total et dont les données ne sont pas anonymisées. Nickel pour transmettre des données critiques à des prestataires qui n'ont pas les habilitations pour le faire

je ne rentrerais pas dans les détails mais c'était une solution logicielle pour le secteur public.
Et pour se connecter à la machine de la bd, il y avait une sécurité par RDP à deux ou trois niveaux...

Sinon, il y a les petits développement qui perdure et arrive en prod avec une bd installée par un non dba.

J'ai vu TRES souvent le mot de passe de APPS en clair dans les logs d'Oracle Application de développements spécifiques. APPS sous OeBS c'est le root d'Unix

[voran]

par exemple : http://seclists.org/fulldisclosure/2006/Apr/176

Mettre à jour des tables alors que t'es pas sensé avoir les droits c'est facheux je trouve

Et ce n'est pas corrigé ?

J'ai vu TRES souvent le mot de passe de APPS en clair dans les logs d'Oracle Application de développements spécifiques. APPS sous OeBS c'est le root d'Unix

pas top, mais qui a accès aux logs ?

[Invité]

J'ai vu TRES souvent le mot de passe de APPS en clair dans les logs d'Oracle Application de développements spécifiques. APPS sous OeBS c'est le root d'Unix

Ah ouais, encore plus trivial, le mot de passe de sys ou system écrit dans le script du job de sauvegarde automatique (ou autre job...)
C'est fort utile quand le client ne veut pas te donner ces mot de passe... pour raison de sécurité...

[Emmanuel Lecoester]

Et malheureusement, ça représente un pourcentage assez impressionnant !
Quand on voit des bases de prod avec SYSTEM/MANAGER, ou des bases de test, copies conformes de la prod du point de vue des données, où le mot de passe est identique au nom du compte systématiquement (SCOTT/SCOTT)...

le mieux c'est le mec qui t'annonce avoir changer le mdp de system mais tu découvres qu'il ne l'a pas fait pour sys