Le développement de logiciels libres relève, dans la plupart des cas, d’une initiative communautaire.
Une communauté de développeurs s’agglomère autour d’un projet, de manière relativement naturelle, en fonction des intérêts et des compétences des contributeurs.
Ainsi, pour joindre un projet et contribuer à son développement, il faut :

• s’y intéresser. Que ce soit de manière personnelle, ou pour le compte d’une entité qui pousse à le faire contre un intéressement matériel, par exemple.
• l’intéresser. Il s’agit de la fameuse notion de méritocratie que nous trouvons dans nombre de grands projets.

Tout est question de confiance et de légitimité gagnée. Logiquement, un contributeur qui propose ses compétences sur un projet ne reçoit pas au départ une très grande confiance : ses patches sont relus et (éventuellement) appliqués par d’autres, on ne lui demande pas son avis pour les questions d’architecture.
Quand la sauce prend (après quelques patches*(semaines|mois|années)), le projet peut commencer à reconnaître ce contributeur, et à lui attribuer des fonctions officielles. C’est ainsi que l’on gagne son “droit de commit”.

Ce modèle permet aux acteurs de se connaître avant de s’accorder la confiance de modifier le coeur des projets en question.

Bien entendu, les procédures diffèrent selon les projets. Très souvent, tout ceci est extrêmement informel. Mais pour certains gros projets, les choses ont été quelque peu structurées. Le projet Apache, par exemple,

• fait voter les membres pour déterminer si une personne devrait gagner des droits de commit
• exige la signature papier d’un accord au sujet de la propriété intellectuelle du projet : http://www.apache.org/licenses/icla.pdf.

Comme l’ont souligné plusieurs conférences du SSTIC, la sécurité des navigateurs web les plus utilisés est catastrophique. Je ne parle même pas d’internet explorer, le sujet a été exploré de multiples fois. Firefox n’est pas en reste : les worms, bankers et derniers virus en tous genre commencent à le gérer, ce qui souligne bien qu’il est vulnérable, d’une manière ou d’une autre à des attaques (cf la conférence du SSTIC sur Anserin).

Certaines recherches (EDIT : et la pratique) ont montré que Firefox est extrêmement perméable à des attaques visant l’utilisateur final : il est possible d’installer des extensions “fantômes”, c’est à dire que l’utilisateur de firefox n’a aucun moyen de détecter qu’une extension a été installée : aucune confirmation n’est demandée, l’extension n’apparaît pas dans la liste…

Par ailleurs, les extensions Firefox ne sont aucunement bridées : il s’agit de code qui tourne avec les privilèges système de l’utilisateur qui a lancé firefox, ni plus ni moins : une extension peut donc modifier à la volée les pages web avant affichage, envoyer des données confidentielles sur un canal caché, par exemple.

Le tableau n’est donc pas brillant, et les “protections” positionnées par certains sites web sensibles (comme celui de votre banque) ne sont pas de nature à [me] rassurer, puisque, bien sûr, éminement contournables!

Les mesures que je m’auto-préconise sont donc désormais :

– Rester en veille pour voir peut-être un jour l’émergence d’un navigateur conçu dès le départ pour être sécurisé

– Dans l’immédiat, utiliser des navigateurs alternatifs “spécialisés” pour les tâches sensibles. On peut citer, parmi d’autres, Konqueror, epiphany. Avec un peu de chance, ces navigateurs sont trop peu utilisés pour être ciblés par les auteurs de malware (en tous cas, de malware de masse…). Bien que je n’aie pas spécialement plus confiance dans leur design (parfois très proche de firefox d’ailleurs…), j’espère tomber dans une “niche”.

– Dans le même registre, mais de manière un peu plus stricte, s’appuyer sur la sécurité et le système de privilèges sous-jacent : créer des utilisateurs systèmes dédiés à mes tâches “sécurisée” comme payer mes impôts, me connecter sur le site de ma banque… Peut-être un système à trois niveaux pourrait-il se révéler intéressant :

• un compte utilisateur pour le surf en zone non maîtrisée, dont je nettoyerais le profil à chaque démarrage du navigateur
• un compte pour surfer sur les sites dont j’ai l’habitude, mais auxquels je n’accorde pas une grande confiance, dont j’auditerais la configuration aussi souvent que possible. Cette approche est cependant très limitée du fait de la mode du web 2.0… les sites web intègrent des “contenus” venant de leurs utilisateurs ou d’autres sites web…
• enfin, un compte pour les applications sensibles. Avec la même restriction que ci-dessus, mais je me permets d’espérer que les administrateurs du site web de ma banque garderont la clairvoyance de ne pas passer leurs applications en Web 2.0…

– Utiliser des extensions pour améliorer la sécurité de Firefox, comme NoScript. Mais je reste persuadé que cela revient à appliquer des emplâtres sur une jambe de bois.

– Essayer d’auditer régulièrement la configuration de Firefox de chaque utilisateur de mes systèmes, et notamment les extensions installées/activées. J’en dirai un peu plus à ce sujet prochainement car j’ai des choses sur le feu …

On connaissait Echelon, les européens s’y mettent aussi (il n’y a qu’à voir certains appels d’offres de certaines entités françaises reliées à l’armée mais réalisant des tâches proches de la police dans les campagnes françaises)

La résultante logique de cette surveillance généralisée des réseaux est tout simplement le chiffrement. Les acteurs du marché sensibles à la confidentialité de leurs échanges : criminels pédophiles et autres terroristes divers, mais également citoyens sensibles et autres geeks se mettent à utiliser des protocoles chiffrés et , tant que possible, anonymisants.

(Au passage, choisissez bien votre protocole de chiffrement. Par exemple, il semble une mauvaise idée de se fier à des protocoles “améliorés” par la NSA… )

Les entités qui veulent contrôler globalement l’information réagissent donc depuis quelques années en mettant au point leurs propres rootkits (ici et aussi ici). En effet, pourquoi dépenser des ressources énormes pour déchiffrer des protocoles indéchiffrables, alors qu’il est tellement plus simple de manipuler l’information en clair directement sur l’ordinateur de notre cyber-pédo-citoyo-terroriste ?

Monsieur Dupont aura donc bientôt, en plus du robot zombie spammeur, le rootkit de la NSA, celui de la CIA, et un ou deux bons rootkits bien français.
Il sera intéressant de voir comment ces charmants “invités” se partageront l’espace et les ressources : sans doute essayeront-ils un peu de se battre entre eux. Mais peut-être qu’en v2 ils accepteront de collaborer “Salut zombie de la police française, moi, zombie de la CIA, je te laisse analyser les images de M. Dupont mais seulement si tu me laisses m’installer sur l’ordinateur de Madame Michu”.

On devrait tout de suite commencer à écrire le protocole de négociation inter-zombie, ça promet d’être interessant. Bien entendu, officiellement, aucun zombie n’acceptera de négocier avec le spammeur …

Pas une semaine sans qu’on ne découvre des trous de sécurité béants dans des services en ligne, des applications web, les languages eux-mêmes.
Sans compter que les technologies elles-mêmes évoluent à une vitesse conférant au dirty hacking.

Dernière plateforme unifiée d’authentification à la mode, OpenID, et un excellent document expliquant les possiblités génériques de phishing offertes par cette technologie. La conclusion est simple : si on veut partager une authentification avec des milliers d’autres sites web, s’appuyer sur un modèle de secret partagé (le couple login/password) est totalement hors de question, car tout le monde se retrouve à partager les mêmes, pour un utilisateur donné…
Bref, il reste du travail (comme pour le reste ) …

Les services web sont tradiditionnellement très vulnérables, peut-être parce que :

• Beaucoup de développeurs sont peu qualifiés, ou au moins peu sensibles aux problèmes de sécurité
• Ces services sont enrichis par une interaction (entre eux, et avec les utilisateurs) très grandissante, ce qui complexifie à outrance les problèmes de filtrage des données, et les “déports de confiance”

À la louche, quelques outils, dont l’énumération, à défaut d’être originale, pourrait être utile :

• Coté serveur, sécurité web avec PHP : l’incontournable suhosin, relativement simple à déployer
• Toujours coté serveur, un très grand classique est bien sûr mod_security, dont la difficulté de configuration a comme pendant une exceptionnelle souplesse
• Coté client, NoScript est un must, et se montre utilisable avec un minimum de bonne volonté par tout utilisateur
• Pour les [maudits] développeurs qui travaillent avec PHP, voyez aussi ce post de haypo sur le profiling PHP

Linus Torvalds présentait le bazar des Logiciels Libres comme une jungle, un milieu naturel où seuls les projets adaptés à leur environnement survivront.
On peut sans doute étendre ce concept un peu plus largement, et notamment dans le domaine de la sécurité. Les projets qui gèrent réellement la sécurité ont toutes les chances, sur une échelle de temps suffisante, de voir leurs utilisateurs et/ou clients augmenter. Alors que les projets vulnérables devraient voir le nombre de déçus exploser avec le temps.
Dans les faits, ceci peut être sans doute ponderé par de nombreux autres facteurs : utilisabilité, ergonomie, marketing, étendue des fonctionnalités…

Mais après tout, peut-être que des stratégies, qui fonctionnent dans la nature, pourraient être utilisées dans la sécurité des projets d’information?
Par exemple, ces animaux qui prennent l’apparence de prédateurs de leurs prédateurs pour les faire fuire, ou qui essaient de se camoufler totalement pour passer inaperçu… Après tout, n’importe quel partisan d’une sécurité un peu stricte fustige de tels comportements 😉

À pondérer, car les prédateurs sur internet ont beaucoup moins de contraintes à satisfaire pour attaquer…