Une faille de sécurité dans LibreOffice et Open Office, Réactions à la publication du 07/02/2019

[Lionel]

Vendredi dernier, des chercheurs en sécurité ont découvert une même faille dans LibreOffice et Open Office.
La voici illustrée en vidéo.

Elle a déjà été patchée dans LibreOffice, mais pas encore dans Open Office.

[MàJ] Cette faille est également exploitable sous macOS, comme le montre cette vidéo :

Lien vers le billet original

[linus]

Je ne comprends pas en quoi ceci est une faille de sécurité, juste un comportement imprévu, non ?
Ou alors je n’ai pas compris ce que montre cette vidéo.

Puisqu’on est dans les bugs, Mojave (mot que ne connaît pas le correcteur orthographique de Apple) ne cesse de m’avertir que j’ai des applications non optimisées. Problème, il s’agit là d’applications 64bits (vérifié avec la commande Terminal
lipo -info xxxxx
Cela voudrait il dire que Apple n’accepte plus que les applications Apple ?

Autre bug « amusant » iOS vient soudain de décider que nombre de substantifs de ce que j’écris ont une majuscule (non le c’avier N’est pas en Allemand). Chaque fois que je tente de corriger, il scrolle vers le haut dès que je pose le doigt sur l’écran.
Amusant 5’ mais un poil pénible !!!

[Jack the best]

Moi aussi j'ai toutes sortes d'applications qui, selon Mojave, ne fonctionneront bientôt plus !

Par exemple le Pack Office Micro$oft ! Normal, c'est le pack 2008, et il fonctionne tout à fait bien pour ce que j'en fais.

[hellomorld]

Je ne comprends pas en quoi ceci est une faille de sécurité, juste un comportement imprévu, non ?
Ou alors je n’ai pas compris ce que montre cette vidéo.

De ce que j'ai compris de la vidéo, un faux fichier libreoffice, va quand on l'ouvre, lancer Libreoffice, ça c'est normal, mais aussi des commandes shell (et donc potentiellement dangereuses), ce qui peut servir de cheval de troie pour infecter un ordi.

[Guest_Matyu_*]

Pas bien compris la courte vidéo qui montre une interface Windows.
J'utilise LibreOffice sur macOS. Je l'utilise occasionnellement.
Le module de mise à jour ne me propose pas la dernière version,
il faut aller la chercher sur le site et choisir la version "Still" ou "Fresh".

Ce message a été modifié par Matyu - 11 Feb 2019, 23:10.

[SartMatt]

Je ne comprends pas en quoi ceci est une faille de sécurité, juste un comportement imprévu, non ?
Ou alors je n’ai pas compris ce que montre cette vidéo.

Ce qu'il montre dans la vidéo, c'est qu'il arrive à faire un fichier ODT dans lequel il y a un lien hypertexte qui lance la calculatrice Windows dès qu'on passe la souris au dessus.

C'est une faille de sécurité parce que ça veut dire qu'un fichier ODT en apparence inoffensif peut provoquer l'exécution de commandes. Commande inoffensive dans l'exemple, mais on pourrait tout aussi bien mettre à la place une commande allant supprimer des fichiers ou envoyer des fichiers vers un serveur.

[linus]

Je ne comprends pas en quoi ceci est une faille de sécurité, juste un comportement imprévu, non ?
Ou alors je n’ai pas compris ce que montre cette vidéo.

Ce qu'il montre dans la vidéo, c'est qu'il arrive à faire un fichier ODT dans lequel il y a un lien hypertexte qui lance la calculatrice Windows dès qu'on passe la souris au dessus.

C'est une faille de sécurité parce que ça veut dire qu'un fichier ODT en apparence inoffensif peut provoquer l'exécution de commandes. Commande inoffensive dans l'exemple, mais on pourrait tout aussi bien mettre à la place une commande allant supprimer des fichiers ou envoyer des fichiers vers un serveur.

Merci, c’est clair maintenant.

[kwak-kwak]

Je ne comprends pas en quoi ceci est une faille de sécurité, juste un comportement imprévu, non ?
Ou alors je n’ai pas compris ce que montre cette vidéo.

Ce qu'il montre dans la vidéo, c'est qu'il arrive à faire un fichier ODT dans lequel il y a un lien hypertexte qui lance la calculatrice Windows dès qu'on passe la souris au dessus.

C'est une faille de sécurité parce que ça veut dire qu'un fichier ODT en apparence inoffensif peut provoquer l'exécution de commandes. Commande inoffensive dans l'exemple, mais on pourrait tout aussi bien mettre à la place une commande allant supprimer des fichiers ou envoyer des fichiers vers un serveur.

Merci, c’est clair maintenant.

Pour aller plus loin dans l'explication (si d'autres n'ont pas compris).

Sous Windows, comme sous Mac, Linux, etc, il est (bien évidemment) possible de lancer les programmes en ligne de commande.
Le fichier exécutable de la calculatrice Windows s'appelle calc.exe, elle est souvent utilisée en démonstration de hacking car elle est inoffensive, "inutile", autonome et extrêmement simple d'implémentation (imbriquée avec et dans rien). Etre capable d'ouvrir la calculatrice, démontre donc que l'on est capable d’exécuter des lignes de commandes amenant à l’exécution d'un programme quelconque. (Comprendre, l'ouverture de la calculatrice ne peut pas être issue d'un comportement imprévu).

La démonstration ici montre que via un fichier texte .ODT d'apparence inoffensive, il est possible de faire exécuter à OpenOffice / LibreOffice (qui est un éditeur de texte), du code amenant à l'ouverture de la calculatrice (donc qu'il est possible d'exécuter des lignes de commande).


Ce message a été modifié par kwak-kwak - 7 Feb 2019, 22:13.

[ungars]

Je ne comprends pas en quoi ceci est une faille de sécurité, juste un comportement imprévu, non ?
Ou alors je n’ai pas compris ce que montre cette vidéo.

Ce qu'il montre dans la vidéo, c'est qu'il arrive à faire un fichier ODT dans lequel il y a un lien hypertexte qui lance la calculatrice Windows dès qu'on passe la souris au dessus.

C'est une faille de sécurité parce que ça veut dire qu'un fichier ODT en apparence inoffensif peut provoquer l'exécution de commandes. Commande inoffensive dans l'exemple, mais on pourrait tout aussi bien mettre à la place une commande allant supprimer des fichiers ou envoyer des fichiers vers un serveur.

Merci, c’est clair maintenant.

Pour aller plus loin dans l'explication (si d'autres n'ont pas compris).

Sous Windows, comme sous Mac, Linux, etc, il est (bien évidemment) possible de lancer les programmes en ligne de commande.
Le fichier exécutable de la calculatrice Windows s'appelle calc.exe, elle est souvent utilisée en démonstration de hacking car elle est inoffensive, "inutile", autonome et extrêmement simple d'implémentation (imbriquée avec et dans rien). Etre capable d'ouvrir la calculatrice, démontre donc que l'on est capable d’exécuter des lignes de commandes amenant à l’exécution d'un programme quelconque.
La démonstration ici montre que via un fichier texte .ODT d'apparence inoffensive, il est possible de faire exécuter à OpenOffice / LibreOffice (qui est un éditeur de texte), du code amenant à l'ouverture de la calculatrice (donc qu'il est possible d'exécuter des lignes de commande).

Texte original : "I started to have a look at Libreoffice and discovered a way to achieve remote code execution as soon as a user opens a malicious ODT file and moves his mouse over the document, without triggering any warning dialog."
"So I opened the created ODT file and moved the mouse over the link and to my surprise the python file was executed without any warning dialog."
https://insert-script.blogspot.com/2019/02/...emote-code.html
A priori, cela semble limité à du code local. A priori.
Rien sur ce problème côté Apache OpenOffice : https://www.openoffice.org/security/bulletin.html

Ce message a été modifié par ungars - 7 Feb 2019, 22:27.

[baron]

A priori, cela semble limité à du code local. A priori.

Dans la mesure où un fichier .odt est en fait un dossier .zip, il pourrait très bien véhiculer lui-même ledit code malicieux, sans qu'on puisse s'en douter, me semble-t-il…

[SartMatt]

A priori, cela semble limité à du code local. A priori.

Dans la mesure où un fichier .odt est en fait un dossier .zip, il pourrait très bien véhiculer lui-même ledit code malicieux, sans qu'on puisse s'en douter, me semble-t-il…

Non, il ne peut appeler que des commandes exécutables par le système. Ce qui exclu la possibilité de lancer un exécutable contenu dans une archive Zip. Il faudrait d'abord le sortir de l'archive pour pouvoir le référencer dans une commande, on ne peut pas demander au système d'exécuter C:\toto.zip\toto.exe ou /toto.zip/toto.

Il a aussi essayé d'intégrer du code Python dans le fichier avant l'archive Zip, pour exécuter ce fichier Python, il n'a pas réussi, LibreOffice fait la tronche quand le fichier contient autre chose en plus de l'archive Zip :

The idea was to abuse the path traversal to traverse down into the users Download directory and load the ODT file as a python script (ergo creating a polyglot file, which is a python file + a working ODT file). Sadly this was a dead end as well as LibreOffice does not like any data before the ODT Zip header.

Par contre, en plusieurs fois, il doit y avoir moyen de faire des choses... Une première commande qui va par exemple appeler wget (ou équivalent sous Windows, si ça existe en natif) pour télécharger un exécutable, une seconde pour le rendre exécutable, une troisième pour l'exécuter... Mais du coup ça veut dire trois déclenchement successifs, qui doivent se faire dans le bon ordre, ce qui est loin d'être garanti quand il s'agit de déclenchements lors du survol d'un élément par la souris...

Une autre solution peut être d'utiliser un pipe. Sous Linux, ça marche bien avec le os.system de Python :

Code

>>> os.system('ls /tmp | grep pulse')
  pulse-PKdhtXMmr18n

Sous Windows je sais pas.

Donc là il y aurait moyen de faire par exemple un wget <url d'un script bash> | bash, et c'est la fête (ou un unzip pour sortir un exécutable du fichier ODT)

Mais la syntaxe pour l'appel Python dans le fichier ODT n'est pas tout a fait une syntaxe Python de base, on voit qu'il passe une chaîne sans délimiteur en paramètre de la fonction qu'il appelle :

Code

../../../program/python-core-3.5.5/lib/pydoc.py$tempfilepager(1, calc.exe )

Du coup je sais pas s'il peut passer une chaîne un peu plus compliquée qu'un bête "calc.exe", et notamment une chaîne avec des espaces...

Ce message a été modifié par SartMatt - 8 Feb 2019, 00:28.

[baron]

De fait. Merci.

J'avais posté un peu vite puis j'ai bien lu les liens donnés et j'arrivais à la même conclusion — mais entretemps tu avais déjà répondu, bien plus clairement que je n'aurais pu le faire.

[SartMatt]

J'avais posté un peu vite puis j'ai bien lu les liens donnés et j'arrivais à la même conclusion — mais entretemps tu avais déjà répondu, bien plus clairement que je n'aurais pu le faire.

J'ai édité, j'ai pensé à une solution potentielle entre temps. Mais pas sûr que ça puisse marcher, et la flemme d'installer LibreOffice pour tester

[marc_os]

Je ne comprends pas en quoi ceci est une faille de sécurité, juste un comportement imprévu, non ?
Ou alors je n’ai pas compris ce que montre cette vidéo.

Ce qu'il montre dans la vidéo, c'est qu'il arrive à faire un fichier ODT dans lequel il y a un lien hypertexte qui lance la calculatrice Windows dès qu'on passe la souris au dessus.

C'est une faille de sécurité parce que ça veut dire qu'un fichier ODT en apparence inoffensif peut provoquer l'exécution de commandes. Commande inoffensive dans l'exemple, mais on pourrait tout aussi bien mettre à la place une commande allant supprimer des fichiers ou envoyer des fichiers vers un serveur.

Merci, c’est clair maintenant.

Clair ?
En apparence.
Car les grands penseurs ici ont oublié un petit détail pourtant bien présent dans l'article d'origine :

Tested Operating Systems: Windows + Linux (both affected)

Donc il n'est pas encore avéré que la faille puisse être exploitée sur Mac.*
Bref pourquoi le dire ?
Oui, pourquoi ne pas fournir une information complète quand elle est disponible ?

(*) De plus, peut-on sur Mac « lancer la calculatrice [de l'OS] dès qu'on passe la souris au dessus** d'un lien hypertexte » ? Rien n'est moins sûr.
(**) Donc sans devoir cliquer sur le lien si je comprends bien.

Ce message a été modifié par marc_os - 8 Feb 2019, 12:10.

[SartMatt]

Car les grands penseurs ici ont oublié un petit détail pourtant bien présent dans l'article d'origine :

Tested Operating Systems: Windows + Linux (both affected)

Donc il n'est pas encore avéré que la faille puisse être exploitée sur Mac.

Il ne mentionne pas le Mac car il n'a pas testé sur Mac. C'est l'"avantage" d'un OS fermé et limité à des machines très chères, il y a beaucoup moins de gens pour tester dessus

Mais techniquement, il n'y a absolument aucune raison que le Mac ne soit pas affecté. D'ailleurs, dans son bulletin de sécurité, LibreOffice n'indique aucune restriction à certains OS.

La faille utilise une technologie de script multiplateforme (et c'est bien pour ça qu'elle marche aussi bien sous Linux que sous Windows), et ces scripts sont exécutés par un interpréteur intégré à LibreOffice (donc aucune chance qu'il y ait un comportement différent parce que l'interpréteur varie d'un système à l'autre). Et comme sous macOS une application a tout a fait le droit d'en lancer une autre, le système ne le bloquera pas.

Ce qui peut éventuellement changer d'un système à l'autre, c'est le niveau de dégâts possible, en fonction des exécutables disponibles sur le système et qui peuvent donc être appelés via cette faille. Par exemple, il sera sans doute bien plus facile d'exploiter la faille pour supprimer des fichiers sous Linux/Unix que sous Windows, pour une raison toute simple : il y a beaucoup plus d'outils disponibles sous forme de commandes basiques faciles à manipuler. En particulier, il n'y a pas sous Windows d'exécutable qui permette de supprimer un fichier (del est une commande intégré à l'interpréteur, pas un exécutable externe), alors qu'il y en a une sur tous les Linux/Unix, y compris macOS (rm est un exécutable). De même, les possibilités de téléchargements de fichiers et de scripting avec des commandes natives sont bien plus vastes sous Linux/Unix.

Mais à l'inverse, si on trouve une commande qui permet de supprimer des fichiers sous Windows, ça peut permettre de supprimer bien plus de choses que sous Linux/Unix, car sous Windows l'utilisateur a tendance à avoir plus de droits.

[scoch]

Je ne comprends pas en quoi ceci est une faille de sécurité, juste un comportement imprévu, non ?
Ou alors je n’ai pas compris ce que montre cette vidéo.

Ce qu'il montre dans la vidéo, c'est qu'il arrive à faire un fichier ODT dans lequel il y a un lien hypertexte qui lance la calculatrice Windows dès qu'on passe la souris au dessus.

C'est une faille de sécurité parce que ça veut dire qu'un fichier ODT en apparence inoffensif peut provoquer l'exécution de commandes. Commande inoffensive dans l'exemple, mais on pourrait tout aussi bien mettre à la place une commande allant supprimer des fichiers ou envoyer des fichiers vers un serveur.

Merci, c’est clair maintenant.

Clair ?
En apparence.
Car les grands penseurs ici ont oublié un petit détail pourtant bien présent dans l'article d'origine :

Tested Operating Systems: Windows + Linux (both affected)

Donc il n'est pas encore avéré que la faille puisse être exploitée sur Mac.*
Bref pourquoi le dire ?
Oui, pourquoi ne pas fournir une information complète quand elle est disponible ?

(*) De plus, peut-on sur Mac « lancer la calculatrice [de l'OS] dès qu'on passe la souris au dessus** d'un lien hypertexte » ? Rien n'est moins sûr.
(**) Donc sans devoir cliquer sur le lien si je comprends bien.

Dommage que tu ne sois pas un développeur avec un Mac, tu aurais pu apporter la preuve

[ericb2]

Bonjour,

Je suis content d'avoir désactivé Basic et Java (depuis le début) en ne laissant que la possibilité d'utiliser Python dans OOo4Kids et OOoLight, tous deux basés sur OpenOffice. Et en regardant dans le script python, cela ne fonctionne pas, mais j'ai peut-être mal testé.

Concernant OpenOffice : je me demande comment les devs d'OpenOffice ont pu être mis au courant du bug, quand celui-ci n'a été déclaré que sur le bugzilla de Libre office ? J'ajoute: j'ai bien suivi la démarche du dev qui a rapporté le pb, et bien regardé tout le code mentionné.


@pour marc_os : personnellement, je ne développe plus sur Mac OS X, devenu beaucoup trop compliqué. En plus, je devrais payer pour mettre mon logiciel en ligne (alors qu'il est fourni gratuitement, et sans que les utilisateurs ne soient le produit :-)

P.S. : en attendant, je n'arrive pas à reproduire le bug avec OOoLight et OOo4Kids. À ceux qui veulent tester, tout est là (https://adullact.net/frs/?group_id=717 ).


--
qɔᴉɹə

L'association EducOOo : http://www.educoo.org

https://framagit.org/ericb

https://github.com/ebachard

Ce message a été modifié par ericb2 - 8 Feb 2019, 13:49.

[SartMatt]

Je suis content d'avoir désactivé Basic et Java (depuis le début) en ne laissant que la possibilité d'utiliser Python dans OOo4Kids et OOoLight, tous deux basés sur OpenOffice. Et en regardant dans le script python, cela ne fonctionne pas, mais j'ai peut-être mal testé.
[...]
P.S. : en attendant, je n'arrive pas à reproduire le bug avec OOoLight et OOo4Kids. À ceux qui veulent tester, tout est là (https://adullact.net/frs/?group_id=717 ).

C'est précisé sur le site de l'inventeur de la faille, son exemple ne fonctionne pas sur OpenOffice :

Openoffice does not allow to pass parameters therefore my PoC does not work but the path traversal can be abused to execute a python script from another location on the local file system.

Il y a deux points dans cette faille.

Le premier qui concerne OOo et LO, c'est la possibilité d'exécuter une fonction Python "arbitraire" en connaissant le chemin du fichier qui la contient en relatif par rapport au répertoire de scripts Python de OOo/LO. La portée est limitée, car le répertoire d'installation peut varier d'une machine à l'autre, tout comme les fichiers Python disponibles. Ça peut toutefois être problématique sur les systèmes Linux, où l'emplacement de l'installation est relativement standard et où il y a souvent pas mal de scripts Python. Il y a une seconde limitation, c'est qu'il n'est pas possible de passer des paramètres à la fonction. Ce qui restreint encore grandement les possibilités : on ne peut appeler que des fonctions n'ayant pas de paramètres obligatoires.

Le second point, qui ne concerne que LO 6.1, c'est que dans cette version il y a en plus la possibilité de passer un paramètre au script. Et il y a en prime dans un des fichiers Python livrés avec LO (et dont on sait donc l'emplacement relativement au répertoire de scripts de LO) une fonction prenant en paramètre une commande à exécuter. La faille est donc plus dangereuse dans LO 6.1 que dans OOo et LO 6.0.

Le PoC d'Alex Inführ dépend de ce second point, donc ne fonctionne pas sous OOo ou sous une version de LO inférieure à la 6.0.

[marc_os]

Dommage que tu ne sois pas un développeur avec un Mac, tu aurais pu apporter la preuve

Justement, je suis développeur sur Mac, contrairement à certain qui aime affirmer des choses sans vraiment connaître son sujet, mais attention, il parle « théoirie », l'équivalent pour lui de faits vérifiés et avérés...
Enfin, je n'ai pas que ça à faire. C'est pas moi qui est rédacteur ici !

Ce message a été modifié par marc_os - 8 Feb 2019, 14:29.

[ericb2]

@Sarmatt : merci pour le complément d'explication. J'avais bien compris les 2 points : la création du .odt foireux et son utilisation. J'avais bien vu que le passage de paramètres posait problème, mais je n'avais pas tout saisi. Merci pour l'explication.

À l'origine OpenOffice a été conçue pour utiliser plusieurs API, mais via un bridge (un objet, type mandataire, qui établit un lien bidirectionnel entre les API, via une interface, avec de l'assembleur au milieu pour aller plus vite). ça fonctionne très bien pour ça.

Cela permet, entre autres, depuis n'importe quelle partie du logiciel, d'appeler des scripts depuis le C++ (je n'ai jamais eu trop confiance en ce mélange de genres). Maintenant, je m'interroge sur toutes les précautions qu'on doit employer pour interdire ce genre de problèmes, visiblement causés par le mélange de genres (logiciel compilé + script) : on n'ajoute pas les risques, mais on les multiplie !

Enfin, pour ce qui est du path, si on connaît le fonctionnement d'OpenOffice, on devrait pouvoir solutionner ce problème via scp2 (utilisé pour le packaging). Dans ce module, tous les chemins sont normalement mis en dur, et on ne peut pas faire ce qu'on veut. Mais j'ai peut être une vision trop ancienne du problème ;-)

[SartMatt]

Dommage que tu ne sois pas un développeur avec un Mac, tu aurais pu apporter la preuve

Justement, je suis développeur sur Mac, contrairement à certain qui aime affirmer des choses sans vraiment connaître son sujet, mais attention, il parle « théoirie », l'équivalent pour lui de faits vérifiés et avérés...

Puisque tu es développeur, tu devrais pourtant comprendre qu'il n'y a pas de raison technique valable pour que cette vulnérabilité n'affecte pas aussi le Mac Relis les explications d'Alex Inführ, il n'y a strictement rien là dedans qui soit dépendant d'une fonctionnalité du système. Si ça marche sous Windows et Linux indifféremment, sans aucune adaptation, il n'y aucune raison que ça ne marche pas aussi sur Mac. La seule chose qui empêcherait que ça marche, c'est si une application n'avait pas le droit d'en lancer une autre. Ce n'est pas le cas. os.system() dans Python sur Mac permet de lancer une commande. Donc pourquoi appeler os.system() dans la version Mac de LO ne marcherait pas ?

Mais bon, tu es tellement incapable de tolérer la moindre information négative liée de près ou de loin à Apple que même quand ça peut toucher le Mac sans qu'Apple n'en soit responsable, tu ne peut l'accepter...

[captaindid]

cette faille ne doit pas être trop grave vu qu'il y a un pare feu dans open office (selon albanel, ex ministre de la culture, il me semble)

[marc_os]

Dommage que tu ne sois pas un développeur avec un Mac, tu aurais pu apporter la preuve

Justement, je suis développeur sur Mac, contrairement à certain qui aime affirmer des choses sans vraiment connaître son sujet, mais attention, il parle « théoirie », l'équivalent pour lui de faits vérifiés et avérés...

Puisque tu es développeur, tu devrais pourtant comprendre qu'il n'y a pas de raison technique valable pour que cette vulnérabilité n'affecte pas aussi le Mac Relis les explications d'Alex Inführ, il n'y a strictement rien là dedans qui soit dépendant d'une fonctionnalité du système. Si ça marche sous Windows et Linux indifféremment, sans aucune adaptation, il n'y aucune raison que ça ne marche pas aussi sur Mac. La seule chose qui empêcherait que ça marche, c'est si une application n'avait pas le droit d'en lancer une autre. Ce n'est pas le cas. os.system() dans Python sur Mac permet de lancer une commande. Donc pourquoi appeler os.system() dans la version Mac de LO ne marcherait pas ?

Mais bon, tu es tellement incapable de tolérer la moindre information négative liée de près ou de loin à Apple que même quand ça peut toucher le Mac sans qu'Apple n'en soit responsable, tu ne peut l'accepter...

Je suis surtout incapable de tolérer les procès d'intention et les accusations basées uniquement sur des suppositions « théoriques » et non des faits.
C'est comme les « macro virus » pour Word.
En théorie ils peuvent être exécutés sur Mac, en pratique aussi, sauf que sur Mac par exemple au moment de supprimer le fichier C:\\truc\much\hyper\important.txt, et bien tu sais quoi ? Ça marche pas.

Ce que je tolère mal aussi, ce sont les mensonges par omission, comme par exemple omettre de préciser qu'à c't'heure, il n'y a aucune preuve que cela concerne les Mac.

[SartMatt]

En théorie ils peuvent être exécutés sur Mac, en pratique aussi, sauf que sur Mac par exemple au moment de supprimer le fichier C:\\truc\much\hyper\important.txt, et bien tu sais quoi ? Ça marche pas.

C'est sûr. Mais en mettant un chemin compatible Mac, ça marcherait, non ? Le fait qu'un macrovirus ciblant spécifiquement Windows ne marche pas sur Mac ne signifie en aucun cas que les macros ne constituent pas une faille de sécurité sur Mac ! On ne devrait pas avoir besoin d'expliquer de telles évidences à un développeur...


Et c'est pareil dans le cas de cette faille. On est en présence d'une faille qui permet d'exécuter une commande, via la fonction os.system de Python. os.system, ça existe dans toutes les implémentations de Python (ça fait partie de la lib standard Python). Donc sur la version Mac de Python qui est embarquée dans OOo/LO pour Mac. Il est évident qu'un fichier fait pour lancer un exécutable Windows (comme le calc.exe de la démo) ne fera rien sur Mac. Ni sur Linux d'ailleurs. Mais à l'inverse, un fichier fait pour lancer une commande Unix classique, genre un bon vieux rm, il ne fera rien sous Windows. Par contre il marchera sur Linux (testé et confirmé par l'inventeur) et à toutes les chances de marcher sur tous les autres Unix (donc macOS). Et un fichier fait pour lancer une commande spécifique Mac, il a toute les chances de marcher sur macOS, mais pas sur Windows et Linux. C'est une évidence

os.system sur la version Mac de Python, si on lui passe en paramètre une commande valide, ça exécute cette commande. Tu peux le vérifier dans ton terminal : tu lances python, tu tapes import os puis os.system('ls') et ça va t'afficher le contenu du répertoire où tu étais quand tu as lancé Python.

Donc qu'est ce qui te permettrait de raisonnablement penser qu'en passant une commande valide à os.system via la faille de OOo/LO sur Mac, ça ne marcherait pas ? J'aimerais un argument un peu plus sérieux que "y a pas marqué que ça marche sur Mac sur le site du mec qui n'a pas pu tester sur Mac"... Tu es développeur. Alors raisonne comme un développeur. Pas comme un fanatique avec des œillères en forme de pomme. Techniquement, absolument tout porte à croire que ça marchera.

Et surtout, s'agissant d'une faille de sécurité, la chose raisonnable à faire compte tenu du caractère multi-plateformes de cette faille, c'est bien de considérer que jusqu'à preuve du contraire, la faille est exploitable sur Mac. C'est un principe de base en sécurité. Parce que insister sur " il n'y a aucune preuve que cela concerne les Mac", c'est faire croire aux gens que "ça ne concerne pas les Mac". Donc créer un sentiment de sécurité qui a pour le coup toutes les chances d'être un faux sentiment.

Et je le répète, si chez LibreOffice ils n'ont pas pris la peine dans leur bulletin de sécurité de préciser que ça n'affecte que Windows et Linux, c'est sans doute bien parce que ça affecte tous les OS sur lesquels LO existe.


Maintenant, si tu veux en avoir le cœur net, je veux bien consacrer 1 ou 2h à tester ça sur Mac. Tu me fournis un accès VNC à un Mac, avec LibreOffice 6.1 installé dessus (bien entendu, pas la 6.1.3...) et je regarde. Hé ouais, c'est facile de dire "ça marche pas sur Mac" tant que personne n'a testé...

[Lionel]

PAs croyable, tu as un RTT ?

[marc_os]

En théorie ils peuvent être exécutés sur Mac, en pratique aussi, sauf que sur Mac par exemple au moment de supprimer le fichier C:\\truc\much\hyper\important.txt, et bien tu sais quoi ? Ça marche pas.

C'est sûr. Mais en mettant un chemin compatible Mac, ça marcherait, non ? Le fait qu'un macrovirus ciblant spécifiquement Windows ne marche pas sur Mac ne signifie en aucun cas que les macros ne constituent pas une faille de sécurité sur Mac ! On ne devrait pas avoir besoin d'expliquer de telles évidences à un développeur...


Et c'est pareil dans le cas de cette faille. On est en présence d'une faille qui permet d'exécuter une commande, via la fonction os.system de Python. os.system, ça existe dans toutes les implémentations de Python (ça fait partie de la lib standard Python). Donc sur la version Mac de Python qui est embarquée dans OOo/LO pour Mac. Il est évident qu'un fichier fait pour lancer un exécutable Windows (comme le calc.exe de la démo) ne fera rien sur Mac. Ni sur Linux d'ailleurs. Mais à l'inverse, un fichier fait pour lancer une commande Unix classique, genre un bon vieux rm, il ne fera rien sous Windows. Par contre il marchera sur Linux (testé et confirmé par l'inventeur) et à toutes les chances de marcher sur tous les autres Unix (donc macOS). Et un fichier fait pour lancer une commande spécifique Mac, il a toute les chances de marcher sur macOS, mais pas sur Windows et Linux. C'est une évidence

os.system sur la version Mac de Python, si on lui passe en paramètre une commande valide, ça exécute cette commande. Tu peux le vérifier dans ton terminal : tu lances python, tu tapes import os puis os.system('ls') et ça va t'afficher le contenu du répertoire où tu étais quand tu as lancé Python.

Donc qu'est ce qui te permettrait de raisonnablement penser qu'en passant une commande valide à os.system via la faille de OOo/LO sur Mac, ça ne marcherait pas ? J'aimerais un argument un peu plus sérieux que "y a pas marqué que ça marche sur Mac sur le site du mec qui n'a pas pu tester sur Mac"... Tu es développeur. Alors raisonne comme un développeur. Pas comme un fanatique avec des œillères en forme de pomme. Techniquement, absolument tout porte à croire que ça marchera.

Et surtout, s'agissant d'une faille de sécurité, la chose raisonnable à faire compte tenu du caractère multi-plateformes de cette faille, c'est bien de considérer que jusqu'à preuve du contraire, la faille est exploitable sur Mac. C'est un principe de base en sécurité. Parce que insister sur " il n'y a aucune preuve que cela concerne les Mac", c'est faire croire aux gens que "ça ne concerne pas les Mac". Donc créer un sentiment de sécurité qui a pour le coup toutes les chances d'être un faux sentiment.

Et je le répète, si chez LibreOffice ils n'ont pas pris la peine dans leur bulletin de sécurité de préciser que ça n'affecte que Windows et Linux, c'est sans doute bien parce que ça affecte tous les OS sur lesquels LO existe.


Maintenant, si tu veux en avoir le cœur net, je veux bien consacrer 1 ou 2h à tester ça sur Mac. Tu me fournis un accès VNC à un Mac, avec LibreOffice 6.1 installé dessus (bien entendu, pas la 6.1.3...) et je regarde. Hé ouais, c'est facile de dire "ça marche pas sur Mac" tant que personne n'a testé...

vivi.
Sauf que s'il y avait réellement un problème sur Mac avec LibreOffice, on le saurait déjà, car je doute fortement que tous ces grands chercheurs en sécurité sur Mac n'aient pas testé la chose.
Or, à c't'heure, il n'y a toujours rien.

[SartMatt]

Sauf que s'il y avait réellement un problème sur Mac avec LibreOffice, on le saurait déjà, car je doute fortement que tous ces grands chercheurs en sécurité sur Mac n'aient pas testé la chose.

Tu es scientifique et développeur, et tu arrives à sortir des argumentaires aussi creux et aussi peu scientifiques ? Et tu continues par contre à ne pas donner le moindre argument technique tangible qui pourrait expliquer que cette faille exploitant des technologies multi-plateformes toutes disponibles et pleinement fonctionnelles sur Mac ne marcherait pas sur Mac

Ton nouvel argument, ça serait donc que si quelqu'un avait testé et constaté que ça marche, il l'aurait dit ? Ben moi j'affirme que si quelqu'un avait testé et constaté que ça ne marche pas, il l'aurait dit. Donc avec la même logique que toi, j'arrive à la conclusion contraire. Preuve que c'est un argument complètement bidon Hé oui, on ne voit pas plus de gens disant qu'ils ont testé et que ça ne marche pas que de gens disant qu'ils ont testé et que ça marche. Alors pourquoi l'absence de résultats de tests prouverait que ça ne marche pas ?

La réalité, c'est sans doute plutôt que ça n'intéresse pas beaucoup de chercheurs en sécurité d'aller tester ça sur Mac, pour deux raisons :
1) c'est tellement évident pour eux que ça à 99% de chances de marcher que ça ne vaut même pas le coup d'aller essayer,
2) ils préfèrent sans doute consacrer leur temps à chercher de nouvelles failles plutôt qu'à de tester une faille déjà trouvée par un collègue.


Je vais donc réitérer ma question et ma proposition, même si je sais bien que tu n'y répondras pas (tiens, c'est rigolo, l'autre jour tu m'attaquais parce que j'avais pas répondu dans l'heure à une question, mais toi, comme d'hab, dès qu'on te pose une question un peu sérieuse, c'est silence radio) :
1) Quels sont les arguments techniques qui pourraient expliquer que os.system() qui marche très bien pour exécuter une commande dans toutes les versions Mac de Python et dans le Python livré avec LO sur Windows et Linux ne marche pas dans le Python livré avec la version Mac de LO ? Ce serait quand même fort surprenant, non ?
2) Je t'ai gentillement proposé de faire le test, il te suffit de m'ouvrir un accès VNC sur un Mac pendant le WE et je m'en occupe. Car en scientifique que je suis, je préfère tester plutôt que affirmer que puisque personne n'a dit avoir testé et réussi et que personne n'a dit avoir testé et échoué, c'est que ça ne marche pas



Tiens, une autre du même niveau que toi. On voit dans la vidéo que le PoC a été fait sous Windows 7. Or, je n'ai vu personne confirmer que ça marche sous Windows 8 et Windows 10. Donc je doute fortement que ça marche sous Windows 8 et 10. Si j'avais dit ça au début de ce fil de discussion, tu aurais sans doute débarqué en disant que c'est complètement idiot comme raisonnement, non ? Et bien c'est exactement le même que celui qui te fait dire que ça ne marche pas sur Mac.

[SartMatt]

Du coup je sais pas s'il peut passer une chaîne un peu plus compliquée qu'un bête "calc.exe", et notamment une chaîne avec des espaces...

J'ai creusé. Et je confirme qu'on peut faire des en passant des chaînes plus complexes.

J'ai d'abord essayé de jouer avec notepad.exe en passant un nom de fichier en paramètre. Là je me fait systématiquement jeter, parce que le script Python passe déjà un nom de fichier en paramètre de la commande, et Notepad n'aime pas se retrouver avec deux noms de fichiers concaténés en paramètre...

J'ai fini par trouver l'astuce pour que ça marche : mettre le nom du fichier entre ', avec un espace en plus juste avant la fin. Ainsi Notepad reçoit les deux noms séparés par un espace. Et tout de suite, ça marche mieux (il ignore le second et ouvre le premier).

Ce code me permet d'ouvrir le fichier y:\toto.txt dans Notepad :

Code

tempfilepager(1, notepad.exe 'y:\toto.txt ' )

Passons à l'étape suivante, essayer de supprimer un fichier. J'ai la flemme de chercher un binaire existant en standard dans Windows qui permette de supprimer un fichier. Mais sur ma machine, j'ai Ubuntu on Windows installé. Donc bash.exe. Donc /usr/bin/rm...

Code

tempfilepager(1, bash.exe -c 'rm /mnt/y/toto.txt' )

Et ça marche, ça me supprime bien le fichier /mnt/y/toto.txt Il est donc clair qu'on peut faire des choses beaucoup moins inoffensives que la PoC d'Alex Inführ.

Et du coup, ça doit sans doute aussi marcher sous Linux, en mettant directement :

Code

tempfilepager(1, rm '/tmp/toto.txt ' )

Ou au pire :

Code

tempfilepager(1, bash -c 'rm /tmp/toto.txt' )

Et n'en déplaise à l'ami marc_os, ça doit très probablement aussi marcher sur Mac.


Demain j'essaye de jouer avec wget pour voir s'il y a moyen d'importer du code sur la machine puis de l'exécuter.

[SartMatt]

Me doutant bien que ce cher marc_os n'allait pas donner suite à ma requête, je n'ai pas résisté à la tentation de faire le test par moi même dans une VM Mojave.

Et devinez quoi ? Sans surprise, ça marche sans aucune difficulté, juste quelques adaptations vraiment mineures.

Comme quoi, si l'ami marc_os, au lieu de nous chier une pendule parce que Lionel n'avait pas pris la peine de préciser que la faille n'avait pas été testée sous macOS, avait pris 5 minutes pour laisser s'exprimer la curiosité dont doit faire preuve tout bon développeur et/ou scientifique qui se respecte et tester par lui même la vulnérabilité de la version Mac de Libre Office, on aurait tous gagné du temps (surtout moi... s'il ne m'a pas fallu plus de 5 minutes pour faire marcher la faille sous macOS, ça a été une autre histoire pour faire marcher macOS dans mon Virtualbox...).

Mais bon, c'était sans doute trop lui demander... Et peut-être que, craignant que le résultat aille à l'encontre de ses croyances, il n'osait pas faire le test...

Et comme j'aime bien prouver ce que je dit, je vais donner quelques infos supplémentaires...

Pour commencer, une petit vidéo de l'exploit, sur le même principe que ce qu'à fait Inführ, un fichier qui déclenche l'ouverture de la calculatrice de macOS quand on survole un lien qu'il contient :

https://youtu.be/EbaO-Gxsejg

(ATTENTION : âmes sensibles s'abstenir ! Cette vidéo fait la démonstration d'une faille de sécurité pouvant affecter un Mac ! Des images d'une rare violence. Je décline toute responsabilité en cas de choc, arrêt cardiaque ou toute autre manifestation de terreur)

Ensuite, pour ceux que ça intéresse, le fichier que j'ai créé pour exploiter la faille, en partant du fichier d'Alex Inführ pour Windows : https://share.lurl.eu/macb/CVE-2018-16858-m...calculator.fodt

Fichier à ouvrir avec Libre Office 6.1.0 à 6.1.2 pour que ça marche (personnellement, j'ai utilisé Libre Office 6.1.2.1).

La seule "difficulté" que j'ai eu pour exploiter cette faille, c'est que le packaging de LibreOffice dans un .app pour macOS implique quelques changements dans l'organisation des fichiers. Le chemin relatif pour atteindre pydoc.py à partir du répertoire des scripts Python de LibreOffice n'est pas ../../../program/python-core-3.5.5/lib/pydoc.py mais ../../../Frameworks/LibreOfficePython.framework/Versions/3.5/lib/python3.5/pydoc.py. Il suffit de se placer dans le répertoire LibreOffice.app et de faire un find TableSample.py puis un find pydoc.py pour trouver respectivement le répertoire des scripts et le répertoire de pydoc.py et en déduire le chemin relatif de l'un à l'autre. Ça implique par contre qu'il n'est pas possible de faire un fichier pouvant exploiter la faille à la fois sous macOS et sous Windows ou Linux (sauf en mettant plusieurs liens bien sûr...).

Enfin, on notera une importante différence de comportement, qui peut rendre l'attaque beaucoup plus discrète sur Mac. Sous Windows, on a une fenêtre du terminal qui s'ouvre en plus de l'application qu'on lance. Ce qui fait que même si on lance une application sans interface, on aura toujours au moins une fenêtre qui va s'ouvrir. Sur Mac, on n'a que la fenêtre de l'application. Donc si on lance une application sans interface, l'utilisateur ne voit rien du tout.

Voilà voilà, vous savez tout. Et c'est désormais prouvé, les Mac sont bien affectés par cette faille. "S'il y avait réellement un problème sur Mac avec LibreOffice, on le saurait déjà" qu'il disait Hé bien maintenant, on sait.


Bon, y en aura bien un pour me prétendre que j'ai rien prouvé parce que j'ai utilisé une VM et pas un vrai Mac...

[zero]

Les dernières versions de LibreOffice ont un sérieux problème avec l'indexation d'un document. On ne peux même pas créer un sommaire sans que ça plante. Si l'équipe pouvait régler ça aussi vite que les problèmes de sécurité, ça serait une bonne nouvelle. La version 5.2.7.2 est la meilleure version de LibreOffice. D'ailleurs, elle ne semble pas être touchée par cette faille. Depuis j'ai bien essayé quelques nouvelles versions mais je suis toujours revenu à la même.