Portail OpenOffice

Bien sûr quand on parle de logiciel libre, on parle de licence. En tant qu’utilisateur final, vous n’en avez que faire. Souvent, seule vous importe la gratuité qui vous a été accordée pour son usage. Mais c’est plutôt en tant que développeur, que cette licence prend de l’importance. Suivant celle adoptée par le projet, le travail de codage publié aura des répercussions plus ou moins restrictives. Ici, on ne parle pas de programmeur indépendant, jeune étudiant en codage ou dilettante passionné mais d’abord d’entreprises informatiques qui emploient des développeurs et qui commercialisent des solutions autour du logiciel libre.

OpenOffice depuis sa reprise par la Fondation Apache, est publié sous sa licence éponyme AL v2. Celle-ci est classée dans les licences permissives. Contrairement à LibreOffice qui est sous double licences (MPL v2 et GPL v3) et qui sont elles, classées dans la catégorie « copyleft » et jugées comme restrictives. Ce qu’il faut déjà savoir c’est que ces deux catégories sont incompatibles même si elles se rapportent à des logiciels libres.

Ce paradoxe va permettre ainsi à LibreOffice de profiter de tout code publié par OpenOffice mais à l’inverse, le code publié par LibreOffice ne pourra être repris par OpenOffice.

Car la licence Apache d’OpenOffice impose peu d’obligations. Si une entreprise veut récupérer le logiciel pour le faire évoluer, il devra respecter la paternité de la licence mais pas la redistribution. En clair, s’il y a eu modification du code, elle n’est pas soumise à publication. A l’inverse, la même chose ne sera pas possible avec LibreOffice qui imposera que tout composant développé devra être publié sous la même licence et avec son code source. D’où la présence d’une restriction forte quand il faut contribuer.

Cette approche restrictive peut sembler plus logique dans sa philosophie mais elle a un inconvénient majeur. Elle freine toute usage par des entreprises qui chercheraient à intégrer un logiciel libre sous copyleft. Ainsi en France, le non-respect de la licence expose le contrevenant à une action en contrefaçon, sanctionnée par l’article L. 335-2 du Code de la propriété intellectuelle (les sanctions pouvant atteindre 150.000 € d’amende et 2 ans d’emprisonnement). Il faut faire face à une alternative : répercuter l’engagement avec ses clients ou choisir d’interdire à ses développeurs l’utilisation de logiciels à code ouvert pour les intégrer dans des développements propriétaires. La plupart du temps, le choix est vite fait. Ces projets se privent d’emblée, d’entreprises qui pourraient devenir de futurs contributeurs.

Beaucoup avancent que le copyleft protège le développeur. En fait, il protège d’abord l’entreprise qui emploie le(s) développeur(s). Collabora et CIB, les principales entreprises contributrices du projet LibreOffice, gardent ainsi la main-mise sur leur investissement. Il s’agit de conserver une certaine brevetabilité du code. Ce qui joue un rôle certain dans la valorisation des actifs immatériels de ces sociétés. Un passage en licence permissive aurait donc un impact financier certain. Par exemple, la Fondation Apache estime ses projets pour une valeur supérieure à 20 milliards de dollars.

Qu’on ne s’y trompe pas, la tendance depuis plusieurs années est à la baisse des projets en licence copyleft. En 2019, on n’en comptait plus que 33 %(1) contre 57 % en 2011. Les licences MIT et Apache sont désormais majoritaires.

(1) Source : https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-trends-and-predictions

Depuis cet été, une vague de failles de sécurité touche LibreOffice. Plusieurs rapports ont été ouverts sur le site CVE qui compulse l’ensemble des alertes en informatique. En cause, le module LibreLogo permettant d’avoir un environnement de programmation sous Writer. Développé en Python, il génère depuis août une cascade de correctifs afin d’éviter aux utilisateurs d’ouvrir des documents piégés.

Tout commence avec le CVE-2019-9848. Cette faille permet à un pirate de créer un document malveillant pouvant exécuter silencieusement des commandes sans aucune alerte pour l’utilisateur. La rustine fournie est malheureusement insuffisante puisque d’autres chercheurs en sécurité la contourne et qui génèreront d’autres rapports : CVE-2019-9850 à 52 et CVE-2019-9855.

Rassurez-vous chers lecteurs, OpenOffice n’est pas concerné. Contrairement à ce qu’on peut lire sur les réseaux sociaux, ce n’est pas parce qu’il n’y a pas de nouvelle version chaque trimestre que le ciel va vous tomber sur la tête. Déjà au mois de mars 2019, je vous prouvais que l’exécution de code arbitraire n’était pas possible. Il en va de même avec le reste puisque OpenOffice n’embarque par le fameux LibreLogo dans ses programmes. Vous restez donc en parfaite sécurité.

Dès qu’on parle d’OpenOffice, on voit le nez LibreOffice se pointer.

Suite à ce billet et comme la retape continue sur les réseaux sociaux, toute cette agitation m’a fait penser à ça.

Depuis quelques semaines, regain de cui-cui sur le réseau social éponyme pour annoncer l’énième mort du projet OpenOffice. L’équipe francophone de LibreOffice qui tient le compte Teutteur  tente à nouveau de distiller cette intox :

Ce qu’ils ont du mal à comprendre, c’est que l’utilisateur est seul à décider du logiciel avec lequel il souhaite travailler. Imposer LibreOffice n’est donc pas du goût de tout le monde :

Bref, libre ne veut pas dire systématiquement LibreOffice.

Il y a quelques semaines, une preuve de concept était publiée depuis un blogue autrichien. L’article stipule qu’il serait possible depuis un ODT d’exécuter du code malicieux. Une vidéo floue montre qu’un document ouvert sous LibreOffice 6.1.2 exécute la calculatrice au simple survol d’un hyperlien. Cela sans afficher le moindre avertissement.

La faille serait fixée avec les versions Libreoffice 6.1.4 et 6.0.7 mais l’auteur précise que OpenOffice 4.1.6 serait lui-aussi vulnérable.

Testons alors le fameux document suivant les explications données dans l’article. J’ai copié collé le code et l’ait sauvegardé en FODT. Ce format qui signifie Flat ODT n’est pas normalisé, il a été conçu pour les besoins des développeurs afin de faciliter le débogage de OpenOffice puis plus tard, de LibreOffice. A ce jour, OpenOffice ne sait pas l’importer. L’article indique donc de l’ouvrir sous LibreOffice et de l’enregistrer en ODT. Voilà ! Nous aurions alors maintenant, un document piégé capable de lancer des exécutables à notre insu.

Ouvrons ce document sous OpenOffice et voyons si cela se produit…

Et bien non, une erreur de script s’affiche et rien ne se passe. OpenOffice n’est donc pas concerné.

PS : bien sûr, le code fourni dans le billet du blogue n’est pas adapté car il pointe sur un Python 3.5.5 spécifique à LibreOffice. J’ai donc modifié le fichier avec la version 2.7.6 embarquée dans OpenOffice.

Source : h**ps://insert-script.blogspot.com/2019/02/libreoffice-cve-2018-16858-remote-code.html