Vous trouverez l'article original ici : http://blogs.sun.com/malte/entry/comments_on_the_black_hat. Voici la traduction que j'en ai faite :

Commentaires sur le Black Hat 2009 OOo Security Briefing

Voici mes commentaires sur le livre blanc OpenOffice v3.x Security Design Weakness, Eric Filiol et Jean-Paul Fizaine.

Les déclarations (et non des citations) provenant de l'article sont marquées en italique. Pour le texte original, veuillez vous référer à l'article disponible publiquement.

Chapitre 1 - Introduction

Quelques références aux issues décrites dans "In-depth analysis of the viral threats with OpenOffice.org documents"

Les manipulations du GUI listées et les macros dans l'espace utilisateur ne sont pas au centre de ce nouvel article, je veux donc juste pointer sur mes commentaires de cet article sur mon blog.

Les documents simples, non chiffrés n'ont pas de contrôle de leur intégrité, des fichiers peuvent être ajoutés, incluant du code exécutable

Bien, l'ODF est un standard ouvert, donc toute vérification d'intégrité doit également être bien documentée. Les autres applications ODF doivent être capables de les implémenter, donc un logiciel malveillant sait de quoi a l'air la vérification. Et les formats de fichier binaire (propriétaires) ne sont pas plus sécurisés - ils rendent juste la tâche plus difficile (la sécurité par l'obscurité).

Au bout du compte, cela ne fait rien : si quelqu'un ajoute une macro, OOo enverra un avertissement et demandera à l'utilisateur s'il souhaite vraiment l'exécuter (ce qu'il ne devrait pas faire avec des documents dont il n'a pas confiance). Si le contenu supplémentaire est un exécutable, cela n'a pas d'importance pour OOo dans la mesure où il sera ignoré.

Documents chiffrés : des macros peuvent être ajoutées, remplacées, supprimées

Dans OOo3.0, il n'est plus possible d'ajouter ou remplacer les macros dans les documents chiffrés. Lorsqu'un document est chiffré, tous les services de contenu doivent être signés, tous avec la même clé.

Malheureusement, OOo ne montre qu'un avertissement pour les services non chiffrés des documents ODF 1.2. Pour des raisons de compatibilité/ancienneté, il n'est pas affiché pour les documents antérieurs. Nous travaillons déjà à changer ce comportement pour la version 3.2 puisque nous avons reconnu que la sécurité devrait avoir une priorité plus haute que la compatibilité ici.


MISE A JOUR : Je me trompais en disant que nous affichions cet avertissement. Il est toujours possible de remplacer des macros chiffrés par des macros en texte brut.
Les macros peuvent toujours être supprimées des documents chiffrés. Cela ne peut faire aucun mal, mais je suis d'accord que cela peut sembler étrange à l'utilisateur dans la mesure où il croit que ce ne doit pas être possible dans un document chiffré.

Dans l'équipe qui travaille à l'amélioration de la sécurité dans OOo 3.2, nous avons discuté des solutions possibles ici. Je comprends que Mr Filiol soit en faveur de chiffrer le manifest.xml, mais cela ne peut être fait parce que les algorithmes de hachage/chiffrement sont décrits ici et l'application ODF doit pouvoir le lire. (Vous devez aussi reconnaître que l'ODF 1.2 autorise l'utilisation d'algorithmes de chiffrement différents, parce que différents pays ou différentes entreprises ont différents algorithmes acceptés/autorisés/approuvés).

Notre idée actuellement est de créer un hachage du manifest.xml dans un service différent, qui est chiffré avec la même clé que le reste du document. OOo avertira lors lorsque le hachage est cassé ou n'existe pas. Cela demande des discussions supplémentaires sur la façon d'expliquer l'avertissement à l'utilisateur, parce que OOo avertirait pour d'anciens documents (chiffrés) et pour les documents écrits dans des applications ODF. L'utilisateur aura sans doute besoin d'une option pour désactiver l'avertissement pour les anciens documents.

De plus, nous envisageons d'avertir lorsque des services dans l'archive ne sont pas listés dans le manifest.xml. La spécification ODF statut déjà que seul le contenu listé dans le manifest.xml est pertinent pour le document ODF, donc cela devrait être bon (au contraire de la valeur de hachage chiffrée du manifest.xml qui doit sans doute être spécifiée ici).

Il est possible de supprimer la signature numérique
C'est ok pour moi - cela peut être fait aussi bien avec le GUI de OOo et je ne vois pas de problème ici (dans OOo 3.2, cela ne sera plus guère possible avec les documents chiffrés).

Chapitre 2 - Format ODF et fonctions de sécurité

Format ZIP et ODF et les outils de manipulation

Il y a plusieurs conseils sur la façon de prouver que les fichiers ODF utilisent des containers zip - personne n'a jamais dit que cela devrait être différent. J'aime d'ailleurs beaucoup le conseil du projet ODFToolkit.org : "le but est de fournir un ensemble d'outils pour gérer et manipuler directement et de façon transparente le format OpenDocument".

Dans le contexte de cet article, il semble que ce serait un outil pour faire des choses mauvaises - manipuler des documents ODF. En fait, tout le propos d'un standard ouvert est que différentes sortes d'outils peuvent en faire l'usage. Cela vaut donc la peine de mentionner que le projet a en fait été démarré par des personnes de l'équipe OpenOffice.org ici à Hamburg. Pour rendre l'adoption de l'ODF plus aisée aux autres projets.

Emplacement des macros - la manipulation de simple texte de ces fichiers devrait permettre de considérablement modifier les statuts de sécurité du document
Sure : l'intention des macros est que l'auteur des macros puisse faire des choses puissantes. C'est une bonne chose tout autant qu'une mauvaise. Et l'outil que j'utilise pour les créer n'a aucune importance.

Les personnes ne devraient jamais exécuter une macro s'il ne sont pas sûre de lui faire confiance. Point final

Chiffrage du document : il est très surprenant de remarquer que le manifest.xml n'est pas chiffré

Bien, je ne trouve pas cela surprenant parce que, comme je l'ai écrit plutôt dans cet article, il contient les informations nécessaires à l'application ODF sur la façon de gérer ce chiffrement.

Et comme je l'ai déjà statué ici, nous pensons à introduire une valeur de hachage chiffrée pour le manifest.xml de façon à ce qu'il ne soit plus possible de le manipuler. Les autres informations contenues dans le manifest.xml ne valent pas la peine d'être cachées (surtout le nom des services) sont aussi contenues dans l'en-tête du Zip lui-même.

Signature numérique des documents

Les informations concernant la signature sont situées dans un fichier supplémentaire qui n'est pas le manifest.xml

En fait, le service de signature est listé dans le manifest.xml. Où est-ce que cette affirmation concernant la signature est à propos du fait qu'elle n'est pas stockée directement dans le manifest.xml ?

Cela vaut la peine de mentionner que le META-INF/manifest.xml et META-INF/documentsignatures.xml eux-mêmes ne sont pas signés

Signer le manifest.xml est sur notre liste pour OOo 3.2. Veuillez noter que cela va introduire la limitation que la signature des macros ne pourra être introduite après que le document ait été signé, parce que cela nécessiterait la manipulation du manifest.xml (déjà) signé.

Je ne suis pas sûr de la partie concernant la signature du fichier de signature lui-même. Signer le fichier complet ne serait pas possible, parce que les signatures supplémentaires seraient stockées dans le même fichier, cassant la première signature. Cela demande plus de réflexion/discussion.

La signature numérique repose sur la norme XML-DSIG. Cependant, elle est elle-même non encore standardisée dans la version 1.2 du format OpenDocument (actuellement, aucune information n'est disponible et la seule référence est la version 1.1)

Veuillez noter que la spécification des signatures numériques a été intégrée dans le OpenDocument-v1.2-draft6.odt (Septembre 2007). La version la plus actuelle de la spécification de ODF 1.2 est le Committee Draft 01-rev06.

Tous les aspects relatifs à la signature (voir la page 31 dans l'article) pourrait être intéressant pour tout malware qui pourrait opérer directement dans la mémoire et pourrait ainsi manipuler la signature pendant sa production
Si vous avez déjà du code malveillant s'exécutant dans la mémoire, votre système est déjà compromis et vous ne pouvez vous donc plus vous reposer sur votre système. Vous pouvez lire mon opinion à propos des problèmes de primo infection ici.

Les signatures numériques combinées avec le chiffrement : le fichier de signature lui-même n'est pas chiffré

J'ai discuté récemment avec différentes personnes. Il y a des avantages et des désavantages dans le chiffrement de ce fichier. Cela dépend de votre cas d'utilisation. À la fin, cela peut devenir un problème de vie privé, mais de mon point de vue, pas un problème de sécurité ou d'intégrité.

Signature et macros : Les signatures du document incluent tous les services, alors que la signature de macro n'inclut pas les services du document. Le document n'est pas protégé ce qui est une faiblesse de conception majeure

Je ne suis absolument pas d'accord, dans la mesure où cela fonctionne exactement comme c'est conçu ! Les sociétés ont tendance à faire des tas de choses très compliquées avec les macros. Très souvent ces macros sont situées dans des modèles. Les personnes utilisent le modèle et saisissent des données dans le document. Si les signatures de macro devaient inclure le contenu du document, les signatures de macro deviendraient invalides au moment où l'utilisateur saisirait ses données. Avec l'approche actuelle, les signatures de macro resteront valide dans ce cas. Vous devez aussi noter que les signatures de macros ont une signification différente de la signature de document. Les signatures de macro s'assurent que les macros ne sont pas altérées et peuvent être utilisées pour la décision de confiance de la macro.

Avec les signatures de document, tout le contenu du document est signé, incluant les macros existantes. C'est une évolution significative depuis les versions OpenOffice 2.x, les macros elles-même n'étaient pas signées. En conséquence, les attaques identifiées plus tôt ne fonctionnent plus, du moins directement.

C'est vrai. C'était une mauvaise décision de signer uniquement le contenu du document avec la signature du document. Maintenant, les services de macro (et tous les autres services dans l'archive zip excepté dans le fichier META-INF) font partie de la signature. Veuillez noter que ce n'est que pour des vérifications d'intégrité - les macros signées avec la signature du document ne sont pas gérées comme des macros signées.

Chapitre 3 - Attaques virales à travers des documents OpenOffice simples.

Les manipulations simples d'archive (utilisant un utilitaire zip/unzip et un simple éditeur de texte) permettent de réaliser plusieurs attaques. Si nous avons l'intention de modifier la charge utile du document elle-même (le texte visible du document), le principe consiste en la modification des informations contenues à l'intérieur des balises appropriées

Bien...oui ? Je me demande vraiment pourquoi les gens devraient être perplexes à ce sujet.

Le standard ODF est défini comme un standard ouvert - non lié à certaines applications. Cela signifie que toute application est éligible pour implémenter l'ODF. La plupart des utilisateurs vont utiliser les outils d'édition comme OpenOffice.org pour créer des document ODF. Et c'est tout à fait OK d'utiliser des scripts qui font de l'exécution automatique d'ODF/XML, ou encore d'utiliser le vieux _VI_ où la logique ODF a besoin d'être dans la tête de l'auteur, parce que VI ne peut aider qu'à la manipulation de texte brut.

Ainsi, le scénario décrit ci-dessus est parfaitement valide et bienvenu.

Dans la mesure où il n'y pas de vérification de l'intégrité, la modification demeure non remarquée par l'utilisateur.

Toute sorte de vérification de l'intégrité reposerait sur les hachages. Dans la mesure où le calcul des hachages seraient bien documenté dans la spécification ODF et les algorithmes seraient implémentés dans plusieurs projets open source, cela rendrait bien plus difficile de ne pas reconnaître du code malveillant dans les manipulations du document. Les hachages aident lorsque vous pouvez les chiffrer - c'est exactement à cela que servent les signatures numériques.

Les attaquants peuvent ajouter des fichiers non déclarés (en particulier une ou plusieurs macros malveillantes).

Avec OOo3.2, les fichiers devront être déclarés dans le manifest.xml, mais cela ne change pas grand chose. Pour les macros, ce n'est pas vraiment un problème, dans la mesure où elles ne sont pas encore signées et ne doivent pas être de confiance/exécutées. OOo affichera un avertissement au chargement du document.

La partie "Il est possible d'insérer des données volées dans un fichier OpenOffice.org" est intéressante (En aparté pourquoi les gens les appellent des fichiers OOo si souvent ?! Veuillez noter que ce sont des fichiers ODF et qu'il existe plein d'applications capables de faire de l'ODF autour de nous).

C'est vrai que vous pouvez mettre tout contenu (volé) dans le container zip du document, pas vous pouvez également le faire en attachant les données à des documents PDF, ou personne ne s'attendrait à cela lors de l'envoi du fichier à d'autres. Et vous pouvez sans doute faire la même chose avec beaucoup, beaucoup d'autres formats de fichier.

Le problème ici, de nouveau, n'est pas le format de fichier de l'application, mais la circonstance où vous avez déjà du code malveillant s'exécutant sur votre système ! Ce code peut faire n'importe quoi avec les droits d'accès actifs de l'utilisateur et il y a des attaques bien plus intéressantes/efficaces que de contrôler une application bureautique.

Pour la partie "les attaquants peuvent réaliser des substitutions de macro (remplacer les macros par d'autres macros malveillantes)" :

Comme je l'ai déjà dit, les macros non signées ne doivent pas être considérées comme de confiance/exécutées.

Toute modification conforme au XML restera non détectée...

Je pense que la réponse a déjà été donnée.

Chapitre 4 - Attaques virales à travers des documents OpenOffice chiffrés

Je dois admettre que je ne comprends pas ce que le chapitre 4.1 tente de démontrer. Le texte ne mentionne pas quels types de manipulations de document/macro ont été réalisées dans le "cas réussit". Les différences qu'ils listent (les noms des répertoires dans l'en-tête du zip) ne veut rien dire pour l'ODF et les signatures. Je peux seulement supposer qu'ils ont utilisés de vieux documents dans leurs tests. Comme je l'ai statué plus tôt, certaines vérifications ne sont faites que sur les documents ODF 1.2 (pour des raisons de compatibilité) et à partir de la version OOo 3.2, nous envisageons de faire les mêmes tests et avertissements également pour les anciens documents.

Considérons alors le cas qui consiste à remplacer une macro chiffrée par une macro en texte brut (malveillant).

Cette attaque ne fonctionne plus avec les documents OOo 3.0 et ODF 1.2. À nouveau - les mêmes vérifications pour les documents plus anciens seront introduites dans OOo 3.2. Je suis vraiment désolé que nous ne l'ayons pas fait depuis le début, "seulement" pour des raisons de compatibilité.

Chapitre 5 - Attaques virales à travers des documents OpenOffice signés numériquement.

Dans la mesure où des fichiers critiques ne sont pas chiffrés et surtout il n'y a pas de gestion externe sécurisée des clés de signature numérique et de certificat (utilisation de PKI), il est considérablement facile de forger un certificat X509 faux et de jouer des attaques de l'homme-du-milieu (man-in-the-midle).

Tout d'abord, je voudrai clarifier que OOo fait l'usage de PKI.

Sous Windows, l'API Microsoft Cryptography est utilisée et la gestion de certificats et les outils sont les mêmes que pour toutes les applications Windows. Sur les autres plateformes, OOo repose sur NSS, ce qui signifie que les certificats sont gérés à travers Mozilla Thunderbird, Firefox ou Mozilla/SeaMonkey.

Dans l'article, nous voyons un exemple de quelqu'un qui peut collecter des données personnelles d'"Alice" et créer un certificat auto-signé en utilisant la plupart des données, pour le faire apparaître comme "authentique". Bob reçoit alors un document qui semble signé par Alice et Bob ne comprend pas la PKI et se fait avoir en lisant simplement le nom "Alice". Il ne vérifie pas la clé publique...

Je suis d'accord sur le fait qu'il doit y avoir plein de monde autour de nous qui ne connaît rien aux certificats de clé publique et la PKI. Ils ne comprennent pas qu'un certificat auto-signé n'ont aucune valeur et qu'ils auront d'une manière ou d'une autre, besoin de vérifier la clé publique.

Mais actuellement, OOo 3.0 dit à l'utilisateur lorsqu'un certificat ne peut être validé, ce qui est toujours le cas avec des certificats auto-signés. Il semble que la copie d'écran dans l'article a été faite à partir d'une ancienne version de OOo. Les version OOo 3.x devraient montrer un point d'exclamation dans le signe de signature. Aussi bien dans la barre d'état que dans la boîte de dialogue de certificats.

Copie d'écran montrant ce qu'il en est dans OOo 3.x :

Veuillez noter que le document n'est pas marqué comme "(Signé)" dans la légende de la fenêtre du document, et notez aussi le point d'exclamation sur tous les symboles. Toutes les boîtes de dialogue disent à l'utilisateur que le certificat ne peut être validé. Donc on devrait s'apercevoir que quelque chose ne vas vraiment pas.

À la place, ils ne devraient croire que des certificats signées par certaines autorités de certificat, avec la racine correspondante et des certificats intermédiaires existants sur leur ordinateur.


Cela a l'air bien plus digne de confiance pour l'utilisateur, n'est-ce pas ?

Chapitre 6 - Conclusion : Améliorer la sécurité de OpenOffice

Ma conclusion est que la sécurité de OOo/ODF n'a pas l'air aussi mauvaise que statué dans l'article.

Et avec OOo 3.2, il devrait y avoir des améliorations, comme mentionné à différents endroits dans cet article. Veuillez notez que je ne peux faire de promesse à propos de tout ce qui sera dans la 3.2, nous sommes en train de travailler dessus...

L'idée d'une version spéciale de OOo ("Trusted OOo") dans l'article est intéressante mais signifierait de créer une île. Cette version spéciale avertirait à chaque fois que vous chargez un document qui a été créé/modifié avec une version OOo originale ou tout autre application ODF. Les informations supplémentaires dans le document seraient perdues une fois éditées avec certaines autres applications.

En ce qui concerne l'autorisation pour les administrateurs de configurer les options de sécurité : c'est déjà possible. Modifiez simplement la configuration dans l'installation de la suite pour qu'elle corresponde à vos besoins et marquez l'élément de configuration comme final. L'utilisateur ne pourra alors pas les modifier ou les écraser dans la configuration de l'utiliseur via UI ou une manipulation directe du XML. Et bien sûr vous devez vous assurer qu'un utilisateur normal ne peut écrire à l'endroit où OOo est installé.

Je crois que je n'ai pas de commentaires à faire sur "fermer les parties (relatives à la sécurité) de OOo". En dehors du fait que ce n'est pas un option, cela rendrait les attaques de logiciel propriétaire plus difficiles, mais pas impossibles.



Malte a ajouté une rectification à ce post, dont vous trouverez le texte original sous ce lien

Je dois corriger quelque chose que je viens juste d'écrire dans mon article Black Hat 2009 Security Comments.

Mon collègue qui travaille sur le chiffrement vient de me faire remarquer que nous avons corrigé des macros dans les documents chiffrés qui n'étaient parfois pas chiffrées, mais nous n'affichons pas l'avertissement que j'ai mentionné. La raison en était (encore) la compatibilité.

Je suis vraiment désolé de ma fausse affirmation à ce sujet et que l'attaque décrite dans l'article (remplacer des macros par des macros en texte brut) fonctionne toujours dans OOo 3.0 et 3.1).

Je ferai de mon mieux pour modifier cela dans la version OOo 3.2 à venir et afficher l'avertissement comme promis....

_
Vous pouvez ajouter vos commentaires directement sur le blog de Malte