Les logiciels libres, une économie coopérative

10.3.2 L'Open Source n'est pas professionnel

Pour beaucoup de sociétés encore, les logiciels libres sont des logiciels créés par des geeks dans le fond de leur garage. Ces logiciels sont donc de mauvaise qualité et présentent des failles de sécurité incompatibles avec les besoins très stricts en matière de fiabilité et de sécurité pour un domaine comme le contrôle aérien. Ces idées préconçues sont toutefois entièrement fausses et, pour reprendre les mots de M. Jean-Marc Duflot:

"Quand on voit un gars arriver en Ferrari pour nous parler d'Open Source, on se dit que c'est sorti du garage/"

Il faut savoir que, contrairement à ce que pensent beaucoup de personnes, les projets libres sont très structurés et organisés. Le fait qu'un logiciel soit produit en se basant sur la collaboration ne veut pas dire que n'importe qui peut y faire n'importe quoi. Dans la communauté Open Source, les nouveaux sont exclus de la participation aux gros projets jusqu'à ce qu'ils aient pu démontrer leurs capacités et tout est toujours scrupuleusement surveillé afin de ne laisser passer aucune faille.

10.3.3 On ne peut gagner de l'argent avec le modèle libre

Beaucoup de personnes voient encore les logiciels libres développés par des amateurs bénévoles mais les choses ont changé. Même s'il y a certainement toujours autant de bénévoles qu'auparavant, plus des trois-quarts des logiciels libres sont aujourd'hui développés par des professionnels payés par de grandes sociétés informatiques comme IBM. Cela leur permet de réduire les coûts initiaux de l'investissement. Comme expliqué dans la théorie, les sociétés distribuant les logiciels augmentent leurs bénéfices en réduisant les coûts de production mais aussi en vendant plus. Même si, ce qui n'est pas obligatoire, la société distribue gratuitement le produit développé, elle sera en position dominante pour fournir des services payants concernant ce produit grâce à l'expertise acquise durant la phase de production et développement.

10.3.4 L'Open Source n'est pas sûr

Comme je l'ai déjà fait remarquer à plusieurs reprises, beaucoup de personnes voient les logiciels libres comme des logiciels créés par des amateurs d'informatique bénévoles. Outre l'image peu reluisante de ces logiciels, cela pose aussi, pour ces personnes, un soucis de sécurité du logiciel. En effet, ces logiciels sont très certainement remplis d'erreurs de programmation et de failles que des professionnels auraient corrigées immédiatement. En fait, c'est totalement l'inverse. Même dans le cas, loin d'être obligatoire dans le monde libre, où un logiciel serait uniquement développé par des bénévoles, la disponibilité du code source permet toujours d'augmenter les chances de déceler ces erreurs et des les corriger. On appelle ce principe la Loi de Linus²⁹, selon laquelle les problèmes d'un code

29. Raymond, Eric S., La cathédrale et le bazar, s.e., s.l., 1998, p. 5

FIGURE 12.1 - Explication de la faille Heartbleed. Source: xkcd, xkcd: Heartbleed Explanation, 2014, http://xkcd.com/1354/, consulté le 17 avril 2014

59

sont corrigés plus rapidement et plus efficacement s'il existe un nombre de testeurs et de développeurs le plus grand possible. En effet, il paraît logique d'affirmer qu'un code source ouvert à tout le monde sera soumis à plus d'inspections qu'un code fermé, qui ne peut être revu que par quelques dizaines d'informaticiens.

Le cas d'Heartbleed

OpenSSL* est un outil de chiffrement Open Source très répandu, notamment pour la sécurité sur Internet et pour le chiffrement des emails et des messageries instantanées. Le 1e avril 2014, une équipe de sécurité de Google aurait informé l'équipe de développement d'OpenSSL de l'existence d'une faille très importante au sein du code source de cet outil. Cette faille, due à une erreur de programmation, permet de lire des données transmises à OpenSSL. Le 2 avril, la société de sécurité informatique Codenomicon* découvre également cette faille de manière totalement indépendante. Le lendemain, Codenomicon alerte le centre national de sécurité informatique finlandais au sujet de cette faille ³⁰. Enfin, le 7 avril, l'existence du bug, appelé Heartbleed, est dévoilée au public en même temps que la nouvelle version d'OpenSSL, corrigeant la faille.

Le problème avec cette faille est que la version du logiciel posant problème est utilisée depuis mars 2012. Ainsi, cela fait longtemps que des malfaiteurs peuvent avoir découvert ce problème et s'en être servi pour récupérer des données confidentielles comme des mots de passe ou des données bancaires. Cette terrible faille bouleverse fortement la foi envers le modèle libre! Pourquoi a-t-il fallu deux ans pour découvrir une faille alors que les logiciels libres sont censés être plus sécurisés? Le modèle libre doit-il être remis en question? Je ne pense pas, et ce n'est pas non plus l'avis de Simon Phipps³¹. Tout d'abord parce que cette faille est due à un simple oubli de la part d'un programmateur d'OpenSSL qui est passée inaperçue lors de la révision qui se fait avant publication du code. Cela aurait donc très bien pu arriver avec un logiciel propriétaire. La différence, c'est que Google et Codenomicon n'auraient peut-être pas découverts cette faille s'ils n'avaient pas eu accès au code et que, même si quelqu'un avait découvert le problème, il est possible que personne n'en aurait jamais entendu parler et que l'éditeur aurait simplement attendu la publication de la version suivante pour corriger le problème. Tandis que dans ce cas-ci, l'erreur a été corrigée rapidement et la nouvelle version a été publiée immédiatement pour limiter les risques de fuites de données. Heartbleed provient d'une fonctionnalité d'OpenSSL permettant à un utilisateur d'envoyer une requête à un serveur, qui doit répondre s'il est actif.

Comme vous pouvez le voir dans l'illustration au verso de la page précédente, l'utilisa-teur envoie une requête en précisant la taille de la réponse, normalement pour des raisons de sécurité, mais peut demander à ce que le serveur transmette plus de données que la

30. The Sydney Morning Herald, Heartbleed disclosure timeline, 2014, http://www.smh.com.au/it-pro/security-it/heartbleed-disclosure-timeline-who-knew-what-and-when-20140415-zqurk.html, consulté le 17 avril 2014

31. Informaticien ayant travaillé pour IBM puis pour Sun Microsystems, poussant Sun à publier la plupart de ses logiciels en Open Source, et étant actuellement directeur de l'OSI

Deuxièmement, OpenSSL est un service qui est, comme je l'ai déjà dit, extrêmement

60

réponse, ce qui pourrait potentiellement dévoiler les données conservées en mémoire par OpenSSL, comme des mots de passe.

Voici la partie du code principalement responsable de cette faiblesse:

hbtype = *p++; n2s(p, payload); pl = p;

Dans ce code, p peut être vu comme la requête initiale. La première ligne permet de récupérer le type de message (requête ou réponse). La deuxième ligne est une fonction permettant de récupérer la longueur, qui est affectée à la variable payload. La dernière ligne affecte finalement les données restantes à la variable pl, qui contient l'information réellement demandée. Jamais dans ce code, on ne vérifie que la longueur demandée est bien la longueur réelle de l'information! Désormais, un correctif a été appliqué à ce code:

if (1 + 2 + 16 > s->s3->rrec.length)

return 0; /* silently discard */

hbtype = *p++;

n2s(p, payload);

if (1 + 2 + payload + 16 > s->s3->rrec.length)

return 0; /* silently discard per RFC 6520 sec. 4 */

pl = p;

Cette nouvelle version du code vérifie tout d'abord que l'utilisateur ne transmet pas une requête vide (tout en demandant un réponse d'une certaine taille). Ensuite, ce correctif vérifie que la longueur réelle de la requête n'est pas plus petite que la longueur précisée par l'utilisateur. Comme vous pouvez le voir, il ne fallait pas grand chose pour corriger cette erreur, qui est vraisemblablement une simple erreur de distraction de la part du développeur de ces lignes de codes.

Toutefois, il est étrange qu'il ait fallu tant de temps pour que quelqu'un découvre (ou en tout cas dévoile) cette faille. On peut là voir deux problèmes pratiques importants ayant permis ce problème de sécurité informatique.

Premièrement, les experts en informatique s'accordent généralement pour dire que le modèle libre permet des logiciels plus sûrs car le nombre important de personnes ayant accès au code augmente les chances de trouver les failles. Néanmoins, si les gens aiment parfois profiter de ce modèle, y contribuer est autre chose. Ainsi, les utilisateurs considèrent souvent que le logiciel est plus sûr parce qu'il est libre mais c'est faux, dans la pratique. La vérité est qu'un logiciel libre peut être plus sûr, pour peu que les utilisateurs vérifient effectivement le code source. Évidemment, je ne parle pas de tous les utilisateurs lambda du logiciel. Mais ce logiciel est utilisé par énormément de sites Internet, par les banques, par de grandes sociétés qui disposent d'experts en informatique... Ces experts ont-ils seulement vérifié le code source? Aujourd'hui, je me permets d'en douter!

61

répandu et est, évidemment une application critique, d'une importance capitale pour la sécurité informatique. Pourtant, le budget de ce projet, obtenu sur base de dons, est extrêmement faible. Il me semble paradoxal que tant de sociétés utilisent OpenSSL et que si peu soutiennent ce projet. Trouvez-vous normal que des entreprises, comme les banques, qui utilisent cet outil, n'investissent pas pour assurer sa fiabilité? D'après moi, cela démontre l'importance du modèle double-licences utilisé par Red Hat. Le code source d'OpenSSL devrait être ouvert pour permettre de bénéficier des avantages du libre mais il devrait exister une version payante fournie avec support et documentation afin d'assurer un certain budget au projet, qui pourrait alors payer des informaticiens supplémentaires pour vérifier le code source avant publication. Une chose est certaine, les gens attendent énormément du mouvement Open Source mais ce mouvement ne dispose pas du soutien nécessaire pour répondre à la demande. C'est pourquoi il est d'autant plus important d'augmenter le soutien envers l'Open Source.

Pour terminer cette parenthèse sur ce fait d'actualité, je tiens à signaler que, comme me l'a fait remarquer M. Duflot, si cette faille avait été exploitée, et bien que cela ne laisserait pas de trace "informatique", les entreprises utilisant OpenSSL se seraient certainement rendues compte beaucoup plus tôt que des données avaient été volées et utilisées et auraient cherché, et trouvé, cette faille très vite. De plus, il est très difficile de dire quel type d'informations cette faille pourrait avoir effectivement laissé passer.

10.4 La création d'une communauté Open Source en ATM

Après la fin du projet OSIFE, la société Skysoft-ATM* a décidé de mettre sur pied une communauté Open Source, la communauté Albatross. Cette communauté développe et propose des versions libres des produits de Skysoft. En 2009, Skysoft produisait également une étude, nommée Surveillance Products and Open Source Software (SPOSS), pour le compte d'EUROCONTROL afin d'étudier à nouveau le cas de l'Open Source en ATM. Cette étude m'a semblé beaucoup plus optimiste quant à la possibilité d'utilisation d'OSS en ATM que le rapport du projet OSIFE et pourtant, en 2014, EUROCONTROL ne développe toujours pas de logiciel libre d'ATM. C'est toutefois suite à l'étude SPOSS que la communauté Albatross a été créée.

La première option étudiée a été d'héberger le projet sur la plate-forme de la Commission européenne appelée Open Source Observatory and Repository (OSOR), qui avait pour but d'aider à la distribution de logiciels développés par les institutions européennes. Cependant, pour une question d'image, il a plutôt été décidé d'utiliser une forge spécifique à l'ATM: Albatross.

Albatross ayant été fondée et étant gouvernée par Skysoft, les autres sociétés développant des logiciels ATM n'ont aucune envie d'investir dans cette communauté. En effet, tout investissement dans un projet Open Source d'Albatross pourrait être réutilisé par

62

Skysoft. Ce problème fait perdre toute crédibilité à la communauté Albatross, qui n'a manifestement que peu de chances, dans l'état actuel des choses, de s'imposer suffisamment que pour permettre le développement de projets Open Source rentables de grande envergure.