IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Des failles critiques en série dans les bibliothèques XML

Le , par Katleen Erna

0PARTAGES

1  0 
Des failles critiques en série dans les bibliothèques XML, problème résolu ?

Le langage XML (eXtensible Markup Language) est aujourd'hui un acteur incontournable de la scène informatique. Il est principalement utilisé pour le transfert de données et on le trouve presque partout : .NET, SOAP, VoIP, Web Services, SCADA, etc. ainsi que dans certaines infrastructures bancaires.

Aussi, lorsque la société spécialisée en sécurité informatique Codenomicon - qui s'est fait connaitre en 1996, avec le projet de recherche PROTOS (OUSPG) mené par ses fondateurs - a sorti sa suite de tests TR-069 (sur les protocoles des telecommunications) en janvier 2009, il était normal qu'elle s'interesse à XML : "Comme XML est aujourd'hui la base de la majorité des procotoles modernes et systèmes d'information, quasiment tout pouvait être testé" indique Sami Petäjäsoja, chef de produit.

S'ensuivit une batterie de tests de type fuzzing (injection de données multiples dans les entrées d'un programme puis analyse de son comportement)qui allait révéler un nombre important de failles critiques. Quand les bibliothèques XML furent soumises aux tests, de multiples vulnérabilités furent identifiées. Toutes les bibliothèques testées présentaient cette faille.

Le problème fut signalé dès février 2009 par Codenomicon qui se mit immédiatement à travailler avec le CERT-FI (Finnish National Computer Emergency Response Team) afin de trouver un correctif.

Ces failles permettraient notamment à un individu malveillant d'opérer une attaque par déni de service, ou bien d'exécuter du code malveillant à distance. Aux commandes du CERT-FI, Erka Koivunen explique : "XML est aujourd'hui implanté partout, même là où on ne l'attend pas. Il est crucial que les personnes ainsi que les entreprises utilisant des bibliothèques XML affectées par ce problème mettent à jour leurs systèmes. Le problème sera vraiment résolu lorsque les patchs seront disponibles".

De plus amples informations seront données lors du Hacker Halted 2009 qui se tiendra à Miami en Septembre. Codenomicon a promis d'y expliquer en profondeur le mécanisme des failles en question à l'occasion de la sortie de son nouvel outil de tests : DEFENSICS pour XML.

Source : Codenomicon

Sun, Apache et Python travaillent actuellement au développement de correctifs (certains sont déjà disponibles). Pensez-vous que cela réglera le problème ?

L'utilisation massive du XML, peut-elle être remise en cause ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Chuck_Norris
Membre émérite https://www.developpez.com
Le 06/08/2009 à 21:03
L'utilisation massive du XML partout parce que c'est la mode est aberrant. XML peut être bien pour certaines utilisations mais pour beaucoup d'usage il révèle plutôt être de l'ordre du marteau-piqueur pour poinçonner une feuille de papier.

Maintenant je serais bien curieux de savoir comment un format, XML, peut être à l'origine d'un Déni de Service, et ceux quel que soit la bibliothèque utilisée.
1  0 
Avatar de Skyounet
Expert éminent sénior https://www.developpez.com
Le 06/08/2009 à 21:20
Citation Envoyé par Chuck_Norris Voir le message
L'utilisation massive du XML partout parce que c'est la mode est aberrant. XML peut être bien pour certaines utilisations mais pour beaucoup d'usage il révèle plutôt être de l'ordre du marteau-piqueur pour poinçonner une feuille de papier.

Maintenant je serais bien curieux de savoir comment un format, XML, peut être à l'origine d'un Déni de Service, et ceux quel que soit la bibliothèque utilisée.
En fait c'est les parseurs qui sont en cause.

Une fichier XML mal formé peut mener à des fuites de mémoires, des boucles infinies et autres joyeusetés.
1  0 
Avatar de Bapt.ice
Membre habitué https://www.developpez.com
Le 06/08/2009 à 21:49
Appelez ça une mode si vous le voulez, mais ça permet à plusieurs systèmes hétérogènes de discuter aisément, par l'appui de contrats (dtd, xsd, wsdl, etc.) et sans l'embrouille des typages propres aux langages.

Si vous voyez un moyen plus simple de faire communiquer des systèmes de 10 ans de différence, faites le savoir, les entreprises (les plus grandes en particulier) en seront ravies.

PS : je trouve que JSON est beaucoup moins lisible pour les néophytes et que XML peut etre compris par n'importe quel personne d'une entreprise.

PS2 : Bon courage à toutes les entreprises pour mettre à jour leur libs / parseurs XML =))
1  0 
Avatar de entreprise38
Inactif https://www.developpez.com
Le 06/08/2009 à 22:48
Je crois que ce Chuck_Norris parlait plutôt des cas où un simple INI ou Properties suffirait : on voit pas mal de monde pondre de l'xml pour stocker quelques simples clefs-valeurs

Sinon c'est clair, dans les autres domaines, on aurait du mal à se passer de l'xml (comme tu l'as précisé : xsd, wsdl & co).

Sun, Apache et Python travaillent actuellement au développement de correctifs (certains sont déjà disponibles). Pensez-vous que cela réglera le problème ?
=> Oui, tout simplement. C'est ce qu'on appelle une résolution de bug (ici une faille), c'est tout.
De plus, on parle ici d'effets de bord non pas de la part du format XML lui-même, mais de certaines implémentations, implémentations permettant par exemple d'entrer plus ou moins dans une boucle infinie (comme ça a été dit), même si rien n'empêche de les détecter (c'est bien ce que je fais dans une lib perso ^^ : après X boucles, hop, exception levée; ça doit bien être aussi le cas dans la plupart des libs, faut pas déconner).

L'utilisation massive du XML, peut-elle être remise en cause ?
=> Biensûr que non : si l'on devait abandonner une techno juste parce que -un jour- certaines implémentations présentent une faille (temporaire), il n'y aurait plus d'informatique.

Rhaaaalala ces journalistes, toujours à crier la fin du monde

PS : y'a qu'un "p" à Apache
1  0 
Avatar de Katleen Erna
Expert éminent sénior https://www.developpez.com
Le 06/08/2009 à 23:37
Citation Envoyé par entreprise38 Voir le message

Rhaaaalala ces journalistes, toujours à crier la fin du monde
Oh oui, oh oui, qu'est-ce que nous sommes méchants !!!!!!

Citation Envoyé par entreprise38 Voir le message


PS : y'a qu'un "p" à Apache
Corrigé
1  0 
Avatar de ymoreau
Membre émérite https://www.developpez.com
Le 07/08/2009 à 9:35
Je trouve ça étonnant que TOUS les parseurs XML aient la même faille, à moins qu'ils soit basés sur des algos/codes communs. Enfin bon une fois détecté, c'est corrigé et on en parle plus.
1  0 
Avatar de saad.hessane
Membre confirmé https://www.developpez.com
Le 07/08/2009 à 10:27
Citation Envoyé par entreprise38 Voir le message
Je crois que ce Chuck_Norris parlait plutôt des cas où un simple INI ou Properties suffirait : on voit pas mal de monde pondre de l'xml pour stocker quelques simples clefs-valeurs
Moi même pour des clefs-valeurs j'utilise du XML. Question maintenabilité. Si tu veux un jour faire une hiérarchie des clés, XML est plus adapté, avec possibilité de description avec attribut...
Et ce n'est pas une petite faille de rien du tout qui va changer ça
1  0 
Avatar de clavier12AZQSWX
Membre éclairé https://www.developpez.com
Le 07/08/2009 à 11:28
j'ai toujours préféré les bons vieux fichiers CSV ou .ini ou .cfg....
c'est tellement simple et light....
1  0 
Avatar de Chuck_Norris
Membre émérite https://www.developpez.com
Le 07/08/2009 à 14:57
Et en ce qui me concerne, je fais de l'AJAJ à la place d'AJAX (XML remplacé par du JSON). C'est bien plus léger et plus efficace. En PHP, une simple instruction convertit une structure PHP au format JSON. Et côté Javascript, le JSON est directement interprété. Nul besoin de générer manuellement puis parser un XML.
1  0