Sygus.net - Mot-clé - april

Netzob : un outil de rétro-conception de protocoles de communication

Sygus — Sat, 14 Jan 2012 00:12:00 +0100

Ce billet pour vous annoncer la sortie d’un outil libre de rétro-ingénierie de protocoles de communication : Netzob*. Il s’agit d’un projet sur lequel je travaille depuis plusieurs mois avec un collègue de travail (@Lapeluche), et qui vient combler un vide apparent en termes d’outils publics d’analyse de protocoles propriétaires.

Plusieurs cas d’usages sont visés à travers cet outil :

le développement d’une implémentation libre d’un protocole de communication propriétaire (ou non documenté) ;
l’analyse de sécurité (fuzzing “intelligent”, avec compréhension du protocole) sur des implémentations de protocoles propriétaires ;
la simulation de trafic réaliste de protocoles de communication propriétaires dans le but de tester des produits tiers (pare-feux, IDS, …) ;
l’analyse de flux de communication inconnus à la recherche de données sensibles ;
etc.

La version actuelle (0.3.1) fonctionne sous Linux, et implémente déjà pas mal de fonctionnalités permettant de capturer des messages depuis différentes sources, d’identifier le format des messages (inférence du vocabulaire) ainsi que la machine à états d’un protocole (inférence de la grammaire).

Les protocoles visés par cet outil ne sont pas simplement des protocoles réseau. L’objectif est de supporter un maximum de canaux de communication, comme le montre la figure suivante. Actuellement, l’outil support les flux réseau, les fichiers PCAP, les flux inter-processus et les fichiers structurés.

Quelques slides présentent brièvement l’outil, les mécanismes et les algorithmes sous-jacents. Il existe également une petite vidéo présentant un panorama des fonctionnalité de Netzob (capture de données à partir d’un fichier, inférence du vocabulaire, construction de la grammaire puis simulation de trafic) sur un cas simple :

http://vimeo.com/34964757

Les infos utiles :

Le site web officiel : http://www.netzob.org
La page de téléchargement : http://www.netzob.org/index.php?page=download

(*NETwork protocol modeliZatiOn By reverse engineering.)

La mémoire sous Linux : analyse de /dev/mem

Sygus — Wed, 03 Jun 2009 00:30:00 +0200

Le système de fichiers /dev sous Linux offre un moyen élégant d'accéder directement aux périphériques d'une machine, et notamment à sa mémoire physique par l'intermédiaire de /dev/mem. L'objectif de ce billet est de présenter le fonctionnement de /dev/mem sur un Linux 2.6.26-2 tournant sur une architecture x86 32 bits, et de voir quelles sont les différentes restrictions d'accès.

/dev/mem offre un accès direct à la mémoire physique du système (mémoire RAM, mémoire graphique, BIOS, etc.). L'analyse de ce fichier peut être facilitée par la lecture d'un autre fichier spécial, /proc/iomem, qui présente le mapping des périphériques au sein de la mémoire physique. Le mapping sur le système étudié est le suivant :

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cffff : Video ROM
000e0000-000e17ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-3ffeffff : System RAM
00100000-002ba4ea : Kernel code
002ba4eb-0037661f : Kernel data
003bc000-0041f57f : Kernel bss
...

Autrement dit, le BIOS est accessible dans l'espace d'adressage physique 0x000f0000-0x000fffff, la mémoire graphique est mappée dans 0x000a0000-0x000cffff, et la mémoire RAM, mappée à partir de 16 Mo (c'est à dire dans la ZONE_NORMAL et dans la ZONE_HIGHMEM : voir cet ancien article), est atteignable entre 0x00100000 et 0x3ffeffff. Ce dernier espace fait 1 Go. Ca tombe bien, c'est précisément la taille de la mémoire RAM de la machine :

$ cat /proc/meminfo 
MemTotal:      1036084 kB
...

/proc/iomem nous informe également de l'emplacement du code du noyau et de ses segments de données .data et .bss. Les éléments du noyau (code et données) sont donc directement accessibles en lecture et en écriture par /dev/mem. Biensur, n'importe qui ne peut pas lire ce périphérique : il faut soit être root, soit donner la bonne capability à un processus non-root. Ce dernier cas de figure est typiquement adapté pour le serveur graphique X, qui dépend de /dev/mem pour récupérer des informations liées à la carte graphique, et dont son exécution avec les privilèges root n'est pas nécessaire (hormis pour l'accès à dev/mem). Il suffit de lui donner la capability CAP_SYS_RAWIO, qui autorise, notamment, l'accès à /dev/mem. Ensuite, il faut placer l'utilisateur exécutant le serveur X dans le groupe kmem. L'exemple suivant illustre la mise en place d'une capability propre à l'exécutable dd, lui permettant de lire dans /dev/mem sans la nécessité d'être exécuté en root.

$ cp /bin/dd /tmp/dd
$ sudo setcap cap_sys_rawio=ep /tmp/dd
$ cat /etc/group
...
kmem:x:15:sygus
...
$ /tmp/dd if=/dev/mem of=/tmp/mem.dump 
1835008+0 enregistrements lus
1835008+0 enregistrements écrits
939524096 bytes (940 MB) copied, 17,7379 s, 53,0 MB/s

L'accès à l'intégralité de la mémoire n'est néanmoins pas pertinent d'un point de vue sécurité : la compromission d'un processus root ou d'un processus ayant la capability CAP_SYS_RAWIO peut permettre à un attaquant d'accéder directement à tout le noyau. Il est heureusement possible de configurer Linux pour limiter l'accès à /dev/mem uniquement au premier Mo de mémoire physique et seulement aux pages mémoire ne correspondant pas à de la RAM (ce qui est suffisant pour faire tourner X). C'est d'ailleurs le comportement par défaut sur Ubuntu, mais pas sur Debian Lenny. La restriction d'accès au premier Mo s'active avec l'option CONFIG_NONPROMISC_DEVMEM introduite sur le 2.6.26 (ou CONFIG_STRICT_DEVMEM sur les versions de Linux depuis le 2.6.27) lors de la compilation du noyau. Voici le résultat d'une tentative de lecture de l'ensemble de /dev/mem :

$ sudo dd if=/dev/mem of=/tmp/mem2.dump 
dd: reading `/dev/mem': Operation not permitted
2056+0 records in
2056+0 records out
1052672 bytes (1.1 MB) copied, 0.149356 seconds, 7.0 MB/s

Hop, bloqué au premier Mo... Ou plus exactement au bout de 256+1 pages mémoires ; la dernière page mémoire étant considérée comme appartenant au BIOS par certains systèmes.

Il existe d'autres mécanismes restreignant l'accès à /dev/mem. Citons le patch GrSecurity qui intègre une protection de l'accès à /dev/mem : il empêche l'accès en écriture sur l'ensemble de la mémoire physique. GrSecurity réalise cependant une exception pour le processus correspondant au serveur X.

Bref, bien que /dev/mem ait longtemps été considéré comme une trou de sécurité important, il est possible de limiter de manière importante ses droits d'accès à la mémoire système (option CONFIG_STRICT_DEVMEM du noyau), ou de limiter l'accès en écriture (patch GrSecurity).

La mémoire sous Linux : cartographie de la mémoire

Sygus — Sun, 08 Jun 2008 22:26:00 +0200

La version 2.6.25 du noyau Linux a vu l'apparition d'une série de patchs écrits par Matt Mackall, qui permettent de connaitre précisément le mapping entre les pages virtuelles et les pages physiques, et tout ceci au niveau userland. Cela se fait par l'intermédiaire des fichiers spéciaux /proc/PID/pagemap, /proc/kpagecount et /proc/kpageflags. Le premier indique les adresses des pages physiques utilisées par un processus précis. Le second montre, pour chaque page physique, le nombre de pages virtuelles qui pointent dessus. En effet, la pagination permet de faire correspondre à une même page physique plusieurs page virtuelles appartenant à des processus différents. Enfin, /proc/kpageflags permet de connaitre le statut d'une page mémoire, qui peut être une combinaison des flags suivants :

#define KPF_LOCKED     0
#define KPF_ERROR      1
#define KPF_REFERENCED 2
#define KPF_UPTODATE   3
#define KPF_DIRTY      4
#define KPF_LRU        5
#define KPF_ACTIVE     6
#define KPF_SLAB       7
#define KPF_WRITEBACK  8
#define KPF_RECLAIM    9
#define KPF_BUDDY     10

Avec toutes ces infos, il est possible d'établir une cartographie de l'utilisation de la mémoire vive. C'est ce que fait l'outil Pagemap-Demo, développé par le même auteur que ces patchs. Le graphique suivant montre la mémoire virtuelle d'un processus (en l'occurence, firefox). On peut voir le segment de code (le ptit truc tout en haut à gauche), ainsi que le tas (le rectangle du haut), le pile et les différentes librairies (en bas). La correspondance avec le nom des segments est faite en lisant les informations délivrées par le fichier /proc/PID/maps. Il suffit donc de survoler un segment pour connaitre à quoi il correspond et sur quelle adresse nous sommes.

Le graphique suivant représente le même processus, firefox, mais après avoir ouvert de nombreux sites web. Le jaune indique les pages les plus récemment ajoutées.

Maintenant, on passe à l'affichage d'une cartographie de la mémoire physique :

Enfin, on peut connaitre clairement comment la mémoire est utilisée :

En blanc : les objets utilisés par l'allocateur slab au sein du noyau.
En rose : les pages ayant le flag dirty activé.
En bleu : les pages utilisées par l'algorithme LRU (Least Recently Used).

Le patch permet également de connaitre la quantité de mémoire physique partagée entre différents processus ainsi que la mémoire physique utilisée uniquement par un processus. Ceci permet d'obtenir une nouvelle valeur, le PSS (Proportional Set Size), qui indique le nombre de pages mémoires divisé par le nombre de processus qui l'utilisent. Une information pertinente pour évaluer la quantité de mémoire utilisée par un processus.

SSTIC 2008 : la sécurité s'invite à Rennes

Sygus — Sat, 07 Jun 2008 20:03:00 +0200

Le microcosme de la sécurité informatique avait rendez-vous les 4, 5 et 6 juin à l'université de Rennes 1 pour une nouvelle édition du SSTIC. L'occasion pour des personnes d'horizons divers d'échanger et de présenter leurs recherches. Comme chaque année, et ce depuis 6 éditions (la 3ème pour moi), l'équipe du SSTIC nous propose une brochette de conférences couvrant les principaux thèmes de la sécurité des systèmes d'information : un peu d'organisationnel et de juridique, des présentations de projets (ERESI, GenDbg, SinFP) et pas mal d'analyses techniques avec aussi bien de la crypto, de la virologie, du reverse que des attaques matérielles, applicatives ou systèmes. L'accent a été clairement mis sur les techniques d'analyses statique et dynamique de code avec des conférences sur des méthodes de rétroingénierie et de déboguage noyau/processus. Des techniques très intéressantes, qui servent aussi bien les intêrets des attaquants (compréhension des vulnérabilités en analysant les patchs de sécurité) que des défenseurs (analyse de malwares pour comprendre comment ils se propagent sur nos systèmes).

En vrac, les points à retenir (ou pas...) :

la possibilité de faire évader de l'information grace aux variations de la vitesse de rotation sur les ventilos des processeurs.
Debian en a pris pour son grade à propos de la faille OpenSSL.
ivanlef0u n'est pas un bot IRC.
le bus Firewire doit définitivement être supprimé sur les machines. Bon ok, l'accès à la mémoire physique par DMA n'est pas nouveau, mais les utilisations possibles sont assez sympas.
il faut tout faire pour éviter les zombies.
le piégeage de processeur offre pas mal de possibilités d'attaques. Mais bon, si on va dans ce sens, on peut imaginer tout un tas de backdoor matérielles. A mon sens, l'hypothèse de départ est quand même à la limite d'être réaliste.
stopper les grands réseaux d'envois de spams/malwares est une utopie à partir du moment ou certains domaines et/ou plate-formes d'hébergements se situent dans des zones juridiquemet inatteignables.
chez INL, ils s'amusent plutôt bien.
le patch pour l'attaque de -nikoteen est le suivant : "so strong, that I can't get through". Et ça marche !!

Un point important cette année, est la volonté de pas mal d'équipes de recherche de diffuser librement les sources de leurs projets. Je pense notamment aux projets ERESI et SinFP, de même qu'à plusieurs outils présentés pendant les rumps sessions. De plus, en regardant les portables présents dans le public, il est frappant de voir qu'un bon nombre utilisent des OS libre, typiquement Linux, avec une majorité de Debian et d'Ubuntu. Il est donc clair que la communauté du logiciel libre est plutôt bien représentée dans le monde de la sécurité. J'ai d'ailleurs croisé quelques têtes aperçues au FOSDEM et aux RMLL.

Plus généralement, il est intéressant de voir que la sécurité "ouverte", par opposition à la sécurité par l'obfuscation, est prédominante dans ce genre de conférence. Le logiciel libre a donc un rôle important à jouer, aussi bien pour assurer l'indépendance technologique d'un état ou d'une société vis-à-vis de solutions propriétaires étrangères, que pour permettre une maîtrise du code exécuté, ce qui est d'autant plus important pour des solutions de sécurité. Et quoi qu'en disent les détracteurs du logiciel libre, qui ne se privent pas de rappeler leurs limites comme dans le cas de la faille OpenSSL/Debian, il n'est pas certain qu'une boîte diffusant un logiciel propriétaire similaire aurait annoncé publiquement et aussi rapidement les détails et les implications d'une telle vulnérabilité. Laissant ainsi leurs utilisateurs dans la méconnaissance du risque qu'ils encourent.

Le contexte légal et politique s'est également fait sentir lors de ce SSTIC, mais moins que l'an dernier, avec quelques remarques et questions du public concernant notamment les limitations que la loi nous impose quant aux investigations sur des binaires. En effet, la loi n'autorise le desassemblage que dans une optique d'intéropérabilité logicielle... et même pas matérielle (!). A ce sujet, je me demande si l'auteur d'un malware peut attaquer en justice une boîte qui aurait desassemblé son programme afin d'en étudier son mécanisme... Bref, qu'en est-il des labo de recherche par exemple chez EADS ou au Celar et de leur légitimité à faire du reverse ? Les intervenants du Celar ont malheureusement rapidement éludé la question.

Finalement, nous avons eu un SSTIC très bien organisé (avec une amélioration notable de l'enregistrement du mecredi matin !), une très bonne ambiance, que se soit pendant les confs, pendant les rumps ou lors du social event. Dommage que beaucoup soient repartis sur Paris rapidement, car la soirée du vendredi soir était... mémorable

La mémoire sous Linux : analyse du fichier /proc/meminfo

Sygus — Fri, 25 Apr 2008 01:07:00 +0200

Dans cet article, je vais tenter d'expliquer les différentes informations que le noyau Linux nous donne au travers du fichier /proc/meminfo. Comme support, je vais afficher les données qui concernent mon système. Il s'agit d'un noyau 2.6.24-1 dans une Debian unstable. Ma machine repose sur une architecure x86 en 32 bits et contient une barrette de 1 Go de mémoire RAM.

$ cat meminfo 
MemTotal:      1036256 kB
MemFree:        191256 kB
Buffers:         51824 kB
Cached:         468392 kB
SwapCached:           0 kB
Active:         398852 kB
Inactive:       404108 kB
HighTotal:      131008 kB
HighFree:          256 kB
LowTotal:       905248 kB
LowFree:        191000 kB
SwapTotal:      524280 kB
SwapFree:       524280 kB
Dirty:              44 kB
Writeback:           0 kB
AnonPages:      282736 kB
Mapped:          82108 kB
Slab:            22552 kB
SReclaimable:    14468 kB
SUnreclaim:       8084 kB
PageTables:       2232 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   1042408 kB
Committed_AS:   880596 kB
VmallocTotal:   114680 kB
VmallocUsed:      7540 kB
VmallocChunk:   105972 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     4096 kB

Commençons par les premières lignes :

MemTotal : la quantité de mémoire vive utilisable (ma barrette fait 1 Go (1 073 742 Ko), mais il y a quelques Mo réquisitionnés par le noyau (visiblement 12 615 Ko)).
MemFree :la quantité de mémoire vive actuellement non allouée.
Buffers : la quantité de mémoire vive actuellement allouée dans des buffers.
Cached : la quantité de mémoire actuellement utilisée en tant que cache (par exemple, des caches pour les transferts vers et depuis le disque dur).
SwapCached : la quantité de mémoire actuellement sortie du swap, mais dont une copie est toujours présente dedans.
Active : la quantité de mémoire vive récemment utilisée.
Inactive : la quantité de mémoire qui n'a pas été utilisée depuis un certain temps (le noyau pioche d'abord dans ces pages s'il a besoin de mémoire).

Sur une architecture x86 32 bits, la mémoire physique est séparée en trois zones. D'une part, la zone ZONE_DMA, qui correspond aux adresses physiques de 0 à 16 Mo. D'autre part, la zone ZONE_NORMAL qui va de 16 à 896 Mo. Et enfin, la zone ZONE_HIGHMEM qui va de 896 à 4 Go (voire 64 Go avec l'extension PAE). Sur ma machine, la mémoire vive remplie donc les 2 premières zones, plus une partie de la ZONE_HIGHMEM.

HighTotal : la quantité de mémoire vive présente dans la zone ZONE_HIGHMEM.
HighFree : la quantité de mémoire vive non utilisée et présente dans la zone ZONE_HIGHMEM.
LowTotal : la quantité de mémoire vive présente dans le zone ZONE_NORMAL.
LowFree : la quantité de mémoire vive non utilisée et présente dans la zone ZONE_NORMAL.

Vérifions :

HighTotal + LowTotal = 131008 + 905248 = 1036256 = MemTotal
HighFree + LowFree = 252 + 57468 = 57720 = MemFree

Chouette, ça colle !

SwapTotal : la taille du swap.
SwapFree : la place disponible dans le swap.

Dans mon cas, le swap n'est pas du tout utilisé (en effet, OpenOffice n'est pas encore lancé... :). C'est également vérifiable avec l'utilitaire swapon :

$ sudo swapon -s
Filename           Type        Size    Used Priority
/dev/mapper/lvm-swap  partition  524280   0   -1

Dirty : la quantité de mémoire en attente d'être écrite sur le disque.
Writeback : la quantité de mémoire qui est actuellement en train d'être écrite sur le disque.
AnonPages : la quantité de mémoire allouée avec la fonction mmap() avec le flag MAP_ANONYMOUS.
Mapped : la quantité de mémoire allouée avec la fonction mmap() à partir de fichiers ou de devices.
Slab : la quantité de mémoire utilisée au sein du noyau, et allouée avec l'allocateur Slab, pour ses propres objets et structures.
PageTables : la quantité de mémoire utilisée en tant que table de pages pour gérer la pagination.
CommitLimit : une estimation de la quantité maximale de mémoire disponible pour être allouée.

Linux sépare la mémoire virtuelle en deux partie. Une première, de 3 Go, et qui contient l'espace d'adressage virtuel d'un processus. La seconde, qui elle fait 1 Go, et qui contient l'espace d'adressage noyau. C'est dans cet espace que seront mappés les zones ZONE_DMA et ZONE_NORMAL. Or, celles-ci ont une taille maximale cumulée de 896 Mo. Il est donc nécessaire d'avoir un autre espace, l'espace d'adressage virtuel du noyau, qui permet d'atteindre les 1 Go évoqués juste avant. La valeur VmallocTotal donne la taille de cet espace.

VmallocTotal : la quantité totale de mémoire de l'espace d'adressage virtuel du noyau.
VmallocUsed : la quantité de mémoire utilisée dans l'espace d'adressage virtuel du noyau.
VmallocChunk : le plus grand bloc contigu de mémoire virtuelle (et non physique) disponible dans l'espace d'adressage virtuel du noyau.
HugePages_Total : le nombre de hugepage allouée. Une hugepage est une page d'une grande taille (sisi :), utilisée par des programmes qui ont des besoins précis de mémoire.
HugePages_Free : le nombre de hugepage disponibles.
Hugepagesize : la taille d'une hugepage.

RMLL - Le logiciel libre s'impose en France

Sygus — Mon, 16 Jul 2007 13:30:00 +0000

[ Article paru sur Rue89 ]

Du 10 au 14 juillet, avaient lieu à l'université d'Amiens les rencontres mondiales du logiciel libre, connues également sous le diminutif RMLL. Une grande manifestation qui rassemblait, pour la 8ème édition, les différents acteurs du domaine. Ici, le monde associatif côtoie le monde de l'entreprise, le monde universitaire, le monde éducatif, les collectivités locales, les grandes administrations ainsi que les simples utilisateurs comme les passionnés. Bref, une vaste communauté où chacun y trouve son intérêt et tiens compte de l'intérêt des autres. Car c'est bien ça le logiciel libre : tout le monde a la liberté de contribuer, et chacun dispose des contributions des autres. Le parallèle avec l'encyclopédie Wikipédia est inévitable. D'ailleurs, les deux communautés sont très proches et sont liées par une même philosophie, celle du partage et de la création de biens communs.

Le logiciel libre sort donc du modèle classique basé sur la concurrence pure, le secret industriel et la logique du brevet. Il a longtemps soulevé des réserves quand à sa viabilité économique. Aujourd'hui, celle-ci ne fait plus aucun doute. De nombreuses études ont validé ce modèle ^[1], mais il y a un indice encore plus flagrant : il suffit de voir le nombre d'entreprises (jusqu'aux plus grosses actuelle : IBM, Sun, etc.) impliquées dans le développement d'applications libres. Le marché du service est lui aussi fortement touché. Nous avons vu la création de nombreuses SSLL, autrement dit des SSII offrant des prestations basées sur du libre. Autre indice : de nombreuses administrations ont effectué un déploiement massif de logiciels libres et fonctionnent actuellement avec des programmes bien connus comme OpenOffice, Firefox, Thunderbird ou Linux. La gendarmerie nationale a été l'un des précurseur en France, avec le déploiement, début 2006, d'OpenOffice et de la suite Mozilla sur son parc informatique. Plus récemment, l'assemblée nationale vient d'équiper ses 577 députés, et autant d'assistants, de postes fonctionnant avec le système d'exploitation Linux et utilisant des logiciels libres, notamment pour la messagerie. Enfin, les grandes villes européennes franchissent peu à peu le pas : Munich et la migration de 14.000 postes, Amsterdam en 2006, ou encore Paris, en juin 2007, qui a annoncé l'équipement des 163 élus de la ville sous logiciels libres. De nombreux pays comme le Brésil, le Chili ou le Venezuela ont également annoncer de pareilles mesures.

Cependant, il serait faux de réduire, comme trop souvent, les avantages du logiciel libre à un simple intérêt comptable. Même si sa base est la libre diffusion du logiciel, des intérêts encore plus fondamentaux sont en jeux. D'une part, l'apport d'une communauté de contributeurs à l'édification de logiciels est indéniablement bénéfique, de part sa réactivité et sa force de proposition. Ensuite, il permet à chaque pays, à chaque administration, de marquer son indépendance technologique vis à vis des grandes sociétés éditrices de logiciels, généralement américaines. D'autre part, sa philosophie et son développement ont mis en avant un point clé qui est l'interopérabilité et l'utilisation de formats ouverts. Cela facilite considérablement les communications dans un monde équipé de systèmes hétérogènes. Les formats ouverts nous rassurent également sur les futures migrations et mise-à-jour par l'assurance d'une continuité du support des formats.

Le libre permet également de combattre des monopoles, là où des entreprises classiques ont toutes les peines du monde. Le marché des navigateurs internet est l'exemple le plus marquant : la constante progression de Firefox (en mars 2007 à 24% de parts de marché et aujourd'hui à 28% en Europe d'après Xiti ^[2]) montre que le monopole de Microsoft sur ce secteur est fortement déstabilisé par un concurrent libre. Au delà du simple combat sur les parts de marché, cette petite révolution a permis d'imposer le respect des standards sur les nouvelles versions des navigateurs et a relancé l'innovation et l'émergence de nouvelles fonctionnalités. Les utilisateurs, mais aussi les développeurs web, en sont donc les grands gagnants. Un second monopole est aussi menacé par le libre, celui des ordinateurs grand-public. En effet, il n'est plus rare, aujourd'hui, de trouver des PC équipés d'une distribution Linux, réduisant au passage le coût de la machine du prix de la licence du système. La vente forcée ou vente liée, qui a permis à Microsoft de constituer son monopole mais qui a également accéléré l'informatisation du grand public, est de moins en moins omniprésente. Beaucoup de travail reste encore à faire sur ce sujet, mais il est possible, désormais, de trouver des alternatives offrant un vrai choix quant au système d'exploitation.

A Amiens, pendant cette rencontre internationale, il a été notamment question de l'intérêt du libre pour le secteur public, avec des projets comme le RGI (Référentiel Général d'Interopérabilité) ou la dématérialisation de l'administration; dans le secteur scientifique avec des projets de plate-formes de calcul, de simulation, de télé-médecine; dans le domaine de la création artistique avec des outils de création graphique comme Blender, The Gimp, de montage vidéo et de création de jeux vidéo; dans le monde de l'entreprise avec l'utilisation de plate-formes facilitant la gestion des relations clients et la gestion interne (comptabilité, planification, management, ressources humaines, etc.); dans le secteur de l'éducation, avec la présentation de distributions spécialisées, d'outils pédagogiques comme AbulEdu ou Gcompris ou de système de gestion d'élèves et de rendu de travaux. Au total, plus de 300 conférences ont été présentées, et environ 1500 personnes d'une cinquantaine de nationalités ont pris part à cette rencontre. Reste que si chacun était d'accord sur le bilan positif du logiciel libre, celui-ci est encore menacé par la volonté d'instaurer les brevets logiciels en Europe. Enfin, la question des verrous numériques (ou DRM), qui a fait largement parlé d'elle lors des discussions sur la loi DADVSI, pose toujours problème car ces verrous sont incompatibles avec des logiciels libres.

Notes

[1] http://www.aful.org/professionnels/modeles-economiques-ll

[2] http://www.xitimonitor.com/fr-fr/barometre-des-navigateurs/firefox-juillet-2007/index-1-1-3-102.html