SOURCE Conference Blog

ric Walter s'est trompé de métier. Il aurait en effet plus sa place en tournée avec le cirque Pinder qu'à vouloir nous expliquer les rouages d'Internet, monde qui lui semble aussi étranger que la sécurité à certains de ses confrères. Aussi, quand il met en garde les internautes contre les si prévisibles campagnes de spam profitant du battage autour d'HADOPI, on reste pensif.

Commencez donc par aller lire l'excellente analyse publiée ce matin par CNIS Mag' sur le sujet. Puis rebondissez sur l'article paru dans Le Monde qui cite les propos tenus lors du "Tchat" de vendredi dernier...

Éric Walter y conseillait aux utilisateurs de se montrer vigilants vis-à-vis de leur courrier électronique. Ceci étant, un conseil, ça ne coûte rien à donner. Aussi, grand seigneur, il leur expliquait également comment faire la différence entre un véritable email de la HADOPI et un spam. Je cite :

Les mails de recommandation de la Hadopi seront simples et 
nominatifs alors que les spams n'ont pas le nom de l'usager.

Alors ni une ni deux, je me jette sur mes boîtaspams pour y trouver, entre autres joyeusetés, des entêtes de ce genre :

From: Shannan Lavina <slavinaar@add.cc>
To: Cedric Blancher <xxx@xxx>
Subject: Free Bonus Viagra100mg pills with every order, 100%

Ou encore :

From: Aubrey Stephany <aubreypstephany_nc@abunayyangroup.com>
To: Cedric Blancher <yyy@yyy>
Sujet: Rep1icaWatches: Swiss Rep1icaWatch, Buy Perfect Watches
       Clones Cheap from $150 lf

Nous disions donc :

les spams n'ont pas le nom de l'usager

Fail^[1]...

omme souvent quand on mélange aviation et sécurité informatique, le buzz ne brille pas par son exactitude. Ainsi, il n'a pas fallu beaucoup attendre pour qu'on rebondisse sur les affirmations du journal espagnol El País et qu'un virus informatique devienne responsable du crash du vol Spainar 5022. Contrairement à d'autres avis probablement plus éclairés, mais moins sensationnels...

Évidemment, l'hypothèse de la compromission d'un ordinateur de bord, l'empêchant d'alerter l'équipage et tuant par son silence 154 des 172 personnes présentes à bord du MD82, a de quoi séduire l'amateur de scoops croustillants. Et de générer son lot de commentaires plus ou moins inspirés chez certains professionnels. Il ne manque plus que la clé USB infectée pour parfaire le scénario du Confiker-like meurtrier...

Il y a quand même quelques personnes qui se posent des questions ou font un peu de follow-up sur leurs billets. C'est rassurant, mais bon, ce n'est pas ça qui va empêcher les esprits les plus fertiles de tourner à fond les ballons... Surtout pour en faire le premier incident du genre...

Évidemment, pour remettre un peu les pieds sur Terre, il faut revenir à la source, à savoir le rapport préliminaire d'incident publié par le CIAIAC^[1]. Et ça tombe bien, parce qu'il est public.

La cause technique de l'accident est un décollage sans volets, configuration impropre sur ce type d'appareil. Les évènements qui ont mené à cette configuration sont multiples, mais semblent résulter principalement d'une revue trop rapide des checklists de décollage par un équipage stressé et ensuite du non fonctionnement du TOWS^[2], équipement de bord censé émettre une alerte vocale pour prévenir l'équipage du problème de volets.

Pas mal d'articles parus sur le sujet spéculent sur une infection du TOWS par un malware. Infection qui expliquerait son absence de réaction. Sauf que comme d'habitude, les choses sont un peu plus compliquées qu'une explication à l'emporte-pièce et la vérité est ailleurs. L'équipage était stressé par un retard imputable à une défaillance matérielle. Alors qu'il se dirigeait vers la piste de décollage, une mesure anormale retournée par une sonde de température^[3] avait conduit à son retour en porte. Or, la sonde en question n'est activée qu'en vol mais il semble qu'elle fonctionnait alors que l'avion était encore au sol.

Le fait que l'avion soit ou non au sol est détecté par des interrupteurs logés dans le train avant. Ils contrôlent des relais qui permettent d'activer ou de couper certains équipements. Parmi ces derniers figurent le RAT, mais aussi le TOWS qui n'est actif qu'au sol. Or ces deux systèmes dépendent du même relais, dont une défaillance est avancée comme hypothèse probable de la coupure du TOWS. Car si le relais en question indiquait que l'avion était en vol au RAT, il fournissait la même information au TOWS, lequel se trouvait donc désactivé. Pas de malware dans le TOWS, difficile d'en loger un dans un relais. Poursuivons...

D'après le rapport, c'était le sixième incident du genre enregistré par le DFDR^[4] de l'appareil. Trois d'entre eux se trouvent consignés dans l'ATLB^[5] de l'appareil. Il s'agit d'un journal technique, opéré par l'airline la compagnie aérienne$$Suite au commentaire de Me Capello...$ sur un système informatique externe à l'avion, dans lequel on répertorie, entre autres, les opérations de maintenance consécutives à des incidents. L'analyse de ce journal permet de remonter des alertes en cas d'occurence d'un même incident. Avec comme conséquence possible de clouer l'appareil au sol pour inspection. Or, aucune alerte n'a été remontée à l'équipe de maintenance ce jour là.

Comment expliquer ce silence ? Le malware, forcément ! C'est donc là que l'hypothèse du système compromis entre en scène. Un système vérolé n'aurait pas averti les équipes de maintenance de la répétition d'un problème de RAT dans l'ATLB, conduisant à une autorisation de décollage qui n'aurait pas due être donnée. CQFD...

Maintenant, je vais me garder de spéculer plus avant sur les causes du silence du système gérant l'ATLB. À ceux qui voudraient le faire, je recommanderai toutefois de considérer les points suivants.

D'abord, le rapport préliminaire ne fait pas mention^[6] de l'absence d'une alerte quant au contenu de l'ATLB. On peut donc s'interroger sur l'importance supposée d'un tel incident, pour autant que ça en soit un. Ensuite, dans un précédent article, El País mentionnait que Spanair se donnait un délai de 24h pour réconcilier les rapports que remontent les équipes de maintenance au sein de l'ATLB. Ce qui amène à se demander si les informations dont disposaient l'équipe de maintenance étaient à jour, et donc susceptibles de les alerter.

Ceci m'inspire que l'hypothèse du malware n'est pas la seule permettant d'expliquer cette absence d'alerte. Et quand bien même ce serait le cas, pourrait-on pour autant parler de malware tueur ? Je vous laisse juger par vous-même...

Video games have come a long way since Pong, Pac Man and Space Invaders. Video games have added $ 5 billion to the economy as shown in a study called "Video Games within the 21st Century: The 2010 Report," for Entertainment Software that was done by Economists Incorporated. Annual growth for the industry went up 10 percent between 2005 and 2009, or seven times the growth of the U.S. economy alone.

Jobs made possible because of video games

Michael Gallagher, CEO of ESA, explained that job creation has grown at a "rapid pace.” It is also making "an essential contribution to our nation's economy while stimulating technological innovations and expanding the impact of games on our daily lives." The survey shows us that 32,000 have jobs with video games usually with an average salary of $ 89,781. Video games have made it possible for numerous in the U.S. to get jobs.

California does it all

California is the largest employer of video game industry workers. It provided more than$ 2.6 billion in direct and indirect compensation to its employees in 2009. The state got about $ 2.1 billion in just revenue.

The next two states to follow are Texas and Washington. Virginia had a large expansion with a 77 percent increase between 2005 and 2009.

Why entertainment is so valuable

Families tend to buy less entertainment things in a recession. Video gaming may seem costly on the surface – consoles cost from $ 200 to $ 500, and PCs cost even more. Games range from $ 20 to $ 60, depending upon their popularity, age, format, etc. Since movie prices have gone up, seems like like video games could be better considering one can spend between 40 and 100 hours playing most of the games bought. Hand-eye coordination gets much better along with development when using video games. The video game industry has had a good effect. The U.S. economy is feeling it.

Find more information on this subject

Theesa

theesa.com/facts/pdfs/VideoGames21stCentury_2010.pdf

Washington State Lt. Gov. Brad Owen knows 'Pong'

youtube.com/watch?v=M-b9wEww9MA

Equilibrium Networks' free/open-source visual network traffic monitoring software is now available for download at http://www.eqnets.com. A video of our enterprise system in action and technical documents detailing our approaches to traffic analysis, real-time interactive visualization and alerting are also available at our website.

Besides a zero-cost download option, we are also offering Linux-oriented installation media and an enterprise version of our system with premium features such as configurable automatic alerting, nonlinear replay, and a 3D traffic display.

Discounts—including installation media for a nominal shipping and handling fee—are available to institutional researchers or in exchange for extensions to our platform.

The software can run in its entirely on a dedicated x86 workstation with four or more cores and a network tap, though our system supports distributed hardware configurations. An average graphics card is sufficient to operate the visualization engine.

près une première réaction remarquée, RIM aurait finalement cédé aux demandes des Émirats. Le constructeur canadien du Blackberry se serait donc engagé à offrir les capacités d'interceptions exigées par les Émirats Arabes Unis et l'Arabie Saoudite pour ne pas se faire fermer leurs marchés. Maintenant, c'est au tour de l'Inde de s'engouffrer dans la brèche.

Certains y voient un précédent de taille. Parce que RIM a toujours vanté la sécurité du système Blackberry en mettant en avant l'impossibilité, même pour eux, d'intercepter le contenu des messages, ces annonces viennent écorner la confiance des utilisateurs, et surtout relancer les vieilles polémiques. Et ceci au moment où, comme par hasard, les autorités allemandes conseillent de laisser le smartphone au placard...

<disclaimer>
Avant de m'aventurer plus loin sur le sujet, je ne saurait trop recommander aux facétieux adaptes de la citation à l'emporte-pièce la lecture d'un précédent billet avant de voir dans ces lignes les prémices d'une position quelconque sur la question. Ce qui suit est un réflexion personnelle, en tant qu'individu, point barre. Ne cherchez pas à y voir autre chose. Merci d'avance. Maintenant que c'est dit, revenons au sujet principal.
</disclaimer>

La confidentialité des échanges sur le système Blackberry est une polémique récurrente. La question de savoir si on peut espionner les Blackberry, et tout particulièrement si RIM s'en est donné les moyens, bien qu'étant restée sans réponse, ne manque pas d'alimenter les réflexions. Car si rien ne prouve que ce soit le cas, il faut bien reconnaître que rien ne prouve le contraire non plus.

Aussi, quand on annonce que RIM se pliera aux demandes des Émirats, les interrogations pleuvent. Et ce, malgré le communiqué qu'il adresse à ses utilisateurs. Communiqué dont la rédaction laisse entrevoir d'intenses séances de réflexions considérant les tournures alambiquées et le vocabulaire de choix. Du coup, les analyses plus ou moins bien inspirées fusent... Seulement, quand on s'attarde sur les réactions et qu'on lit attentivement le communiqué en question, on s'aperçoit que cette polémique n'est en rien différente des précédentes. Et surtout qu'il rien de nouveau dans la paysage.

On sait, depuis le temps qu'on nous l'explique, que les communications entre un BES^[1] et ses terminaux sont chiffrées de bout en bout. Chiffrement dont la clé est négociée lors de l'enregistrement du terminal auprès de son BES^[2] et qui interdit à RIM l'accès à plus que les métadonnées^[3]. D'aucuns en déduisent que si c'était vraiment le cas, on ne pourrait pas intercepter le trafic. Et que si on peut le fait, c'est bien qu'il y a là une porte dérobée. Déduction facile ?

Pour moi, le point clé n'est pas là. Vous remarquerez que le communiqué ne porte pratiquement que sur la sécurité des solutions Blackberry d'entreprise. Et pas de les autres. Comme par exemple celles qui sont fournies par des opérateurs qui opèrent un BES pour leurs clients. Ou le fameux Blackberry Internet Service. Pourquoi ? Parce que la solution RIM ne fournit pas de sécurité de bout en bout, de l'expéditeur au destinataire. Elle ne chiffre que les flux échangés entre le terminal et son BES^[4]. Un peu comme le Wi-Fi : on protège le lien hertzien, le reste est un autre problème. De fait, les emails que vous échangez sont accessibles en clair sur les serveurs qui les stockent. Si cela ne pose pas plus de soucis que ça à une entreprise possédant sa propre infrastructure, il en va tout autrement pour tout ceux qui délèguent l'opération de leur messagerie. Que ce soit à un opérateur, à RIM ou à tout autre tiers. Car dans ce cas, leurs messages se retrouvent tout simplement accessibles chez le prestataire... En clair... Comme ça a toujours été le cas pour n'importe quel service de messagerie hébergé...

Aussi, quand on lit ce qui ressort dans la presse, on ne peut qu'esquisser un sourire. D'abord parce que les soit-disant concessions accordées par RIM n'en sont pas : les emails des utilisateurs de services Blackberry hébergés ont toujours été accessibles par les autorités sur demande auprès du prestataire. Au mieux s'agira-t-il de faciliter l'accès à des données déjà interceptables. Ensuite parce que cela résume bien l'échec de la communication de RIM, puisqu'on en vient même à lui reprocher des problématiques qui ne font pas partie du périmètre de sa solution...
Sans parler des classiques déclarations anonymes de sources proches du dossier qui annoncent, par exemple, la prochaine fourniture par RIM d'une solution d'interception des messageries d'entreprise à l'Inde^[5], en complète contradictoires avec les dires de RIM...

Chacun se fera son idée sur la question. Toujours est-il que RIM se retrouve face à un sacré sac de nœuds. Car ce qui a été unanimement présenté comme des concessions accordées aux Émirats pourrait bien ancrer durablement dans la tête des gens l'idée que le Blackberry serait espionnable...

e retour du SSTIC, Kevin Denis constatait avec un certain dépit que la sécurité TCP/IP semblait ne plus intéresser personne. C'est en effet un domaine où beaucoup croient que tout a été dit, qu'il ne reste plus rien à trouver, bref que l'étudier est une perte de temps. Je suis loin de partager cet avis.

Et je le partage d'autant moins que ce désintérêt s'exprime souvent chez des gens dont l'approche on ne plus surfacique du sujet en font soupirer plus d'un. Pour illustrer ce que j'entends par là, je vais vous parler d'un truc on ne peut plus Old School et parfaitement maîtrisé : la corruption de cache ARP. Et vous montrer combien certains devraient revoir leur classiques avant de se faire mousser à BlackHat...

La corruption de cache ARP, c'est une attaque qui pourrait figurer dans un musée. La RFC décrivant ARP date de 1982, et on trouve ce qui est probablement la première référence à l'attaque dans le numéro 34 de Phrack qui nous ramène en 1991. Depuis le problème a été largement documenté et outillé.

Aussi quand, après une discussion sur fr.comp.securite, Pappy, Valgasu et moi avons décidé d'approfondir la question pour notre article sur le sujet dans le numéro 3 de MISC. C'était en 2002, c'était déjà vieux et il ne s'agissait déjà pour nous que de proposer un panorama des techniques de corruption de cache ARP. Des petites choses comme la corruption de cache avec des requêtes, possiblement dirigées, la mise à jour d'entrées statiques sous Windows et Solaris 8, l'usurpation d'IP étaient peu documentées à l'époque, et un outil complet de génération de trafic ARP restait à écrire.

Rien de révolutionnaire n'est sorti de ce travail, mais le fait de se plonger là-dedans nous a donné l'opportunité, je pense, de faire le tour du sujet et de partager l'expérience. Ça nous a aussi permis de nous en servir efficacement quand le besoin a pu se faire sentir...

Mais revenons à nos moutons. Le problème avec les techniques antédiluviennes de ce genre, c'est qu'au bout d'un moment, certains semblent considérer qu'elles font partie du paysage et que comprendre comment ça marche ne sert à rien. Que c'est chiant. Dans la mesure où il y a des outils pour les exécuter, autant regarder vaguement ce qu'ils font et s'en contenter. J'ai l'impression que c'est exactement le panneau dans lequel sont tombés les gens d'AirTight avec leur histoire de Hole196. Prenez les slides qu'ils ont présentés à Defcon et rendez-vous d'abord à la planche 8. On nous y explique qu'une tentative de corruption de cache ARP par requête en broadcast va se trouver répétée sur le réseau filaire où elle pourra être détectée par un éventuel IDS. L'idée est reprise sur la planche 18 qui compare la corruption dite "Old Style", manifestement détectable, avec leur méthode, forcément furtive et donc plus intéressante.

Sauf que ce n'est pas la réalité du terrain. En 2002, quand nous avons travaillé sur l'ARP cache poisoning, l'outil "Old Style" de l'époque était le célèbre arpspoof du package dsniff. La technique qu'il implémente consiste à envoyer des réponses ARP non sollicitées en unicast vers la machine à corrompre. Technique qui ne correspond donc en rien au scénario proposé dans la présentation et qui, surtout, n'entraîne pas de diffusion sur le réseau filaire quand il est dirigé vers une station Wi-Fi . L'attaque n'a donc aucune raison d'y être détectée par un IDS classique.

On peut aussi corrompre un cache ARP avec des requêtes. Et bien que ce type de paquets soit destiné à être envoyé en broadcast, on préférera de loin émettre des requêtes ARP en unicast. D'aucuns peuvent trouver ça étrange, mais c'est complètement supporté dans la mesure où la couche ARP se contrefiche de savoir comment le paquet est arrivé jusqu'à elle... Là encore, on a un exemple de corruption de cache ARP Old Style qui va passer à travers l'IDS filaire...

En fait, faire de la corruption de cache ARP en broadcast est une approche inutilement bruyante du problème. Approche qu'on ne devrait utiliser que s'il fallait toucher l'ensemble du subnet d'un coup... Exécuter l'attaque en unicast est bien plus efficace, ne serait-ce que du point de vue de la furtivité. Dans le contexte décrit par AirTight, le trafic unicast ainsi produit sera protégé par la PTK et ne génèrera pas la superbe alerte montrée sur la slide 23 du Webinar Hole196.

De manière générale, on peut conclure que le discours soutenant l'intérêt de Hole196 pour faire de la corruption de cache ARP n'est appuyé que par un use case un peu foireux. D'autres méthodes permettent d'arriver au même résultat sans déclencher les alertes annoncées et sans avoir à s'embarrasser de ces histoires de GTK. Les auteurs ignoraient-ils donc l'existence de ces dernières^[1] ? Je ne sais pas, mais ce ne serait pas la première fois que ce genre d'erreur serait faite.

Pas mal de gens ont en effet essayé de produire des techniques de détection, voire même de prévention, de corruption de cache ARP. Et pas mal d'entre elles échouent parce qu'elles ne ciblent que certains scénarios d'exploitation. Or l'expérience montre que ce genre d'approche est vouée à l'échec. Dans notre cas, l'erreur la plus courante consiste à ne surveiller que les réponses ARP, puisque c'est ce que met en œuvre l'outil d'attaque le plus connu. Or c'est l'intégralité du trafic ARP qu'il faut inspecter, comme le fait arpwatch quand on lui envoie l'intégralité du trafic. Ou alors, il faut durcir l'implémentation de la couche ARP, ce que fait ArpOn sous Unix.

Si vous voulez lire quelque chose d'intéressant sur la sécurité Wi-Fi publié à BlackHat et Defcon, je vous conseille de vous tourner vers les travaux de Leandro Meiners et Diego Sor sur le "WPA Migration Mode" de Cisco. Ce mode, qui permet d'accepter des clients ne supportant que WEP ou LEAP sur des réseaux WPA/WPA2 acceptant TKIP, se fait donc démonter dans les grandes largeurs. Le code implémentant l'attaque est disponible et en passe d'être inclus dans Aircrack-ng et probablement dans Kismet.

On sent bien le fail qui s'apparente à équiper un coffre-fort d'une porte en contre-plaqué. Ou une serrure biométrique dernier cri d'un barillet de secours trivial à crocheter^[2]. Bref, quelque chose qui ne viendrait pas à l'esprit d'une personne sensée...

On August 19th, at 10am PST I will be giving a Webinar on the topic of visualization. You can register and watch the Webinar right here:

'édition espagnole de SOURCE se déroulera à Barcelone les 21 et 22 septembre prochains. La conférence se tiendra une nouvelle fois dans l'enceinte du Musée National d'Art de Catalogne, cadre qui ne manque pas d'originalité et permet de s'accorder quelques intermèdes culturels. L'an dernier, par exemple, je me suis régalé avec l'exposition consacrée au photographe Robert Capa.

Le programme (quasi) définitif est en ligne depuis quelques jours et ne manque pas d'intérêt je trouve. Si faire le déplacement en Espagne vous intéresse, j'ai quelques bons de réduction sur l'entrée à la conférence à distribuer.

La conférence sera ouverte par une keynote plénière de William Beer sur les orientations du monde de la sécurité dans les dix ans qui viennent. Elle se terminera avec une intervention également plénière de Vincenzo Iozzo et Giovanni Gola sur la gestion de la confidentialité dans la vraie vie.

Entre les deux, il y aura les deux sessions en parallèle. Côté technique, le programme sera le suivant :

• Philippe Langlois sur l'exploitation des réseaux SIGTRAN et SS7 ;
• Chris Brown sur un sujet cher à Newsoft, à savoir l'échec de la sécurité ;
• Alexandr Polyakov et Ilya Medvedovskiy sur la sécurité des ERP ;
• Carric Dooley et Simon Roses Femerling avec un panorama sur les mots de passe en entreprise ;
• Wim Remes sur les mauvaise pratiques dans l'utilisation d'un SIEM ;
• Josh Abraham et Will Vandevanter sur les BusinessObjetcs de SAP ;
• Barnaby Jack sur les ATM avec son fameux Jackpotting ;
• Vishal Asthana sur la prise en compte de la sécurité en développement rapide ;
• Bruno Oliveira et Jibran Ilyas qui étudieront quelques affaires de piratage, TJX en tête ;
• Iftach Ian Amit sur les relations entre cybercriminalité et cyberguerre ;
• Val Smith avec un talk sur la communauté hacking chinoise.

Côté business, ça donnera ça :

• Allison Miller et Alex Hutton sur la modélisation des menaces ;
• Matt Bartoldus sur la SDL ;
• Richard Stiennon sur la cyberdéfense ;
• Amrit Williams sur les hyperviseurs ;
• Erin Jacobs et Mike Murray sur la carrière des g33ks en sécurité ;
• une session de deux heures sur l'évaluation des antivirus par TrendMicro ;
• Andrew Hay et Chris Nickerson sur le rapprochement des mondes du business et du hacking ;
• Jacob Appelbaum sur l'anonymat et la protection de la vie privée avec Tor ;
• Brian Honan avec un retour d'expérience sur l'implémentation du CERT irlandais ;
• Jayson E. Street également sur la modélisation de menaces.

Globalement, c'est un très bon programme, sur le papier du moins. D'un autre côté, comme je suis en partie responsable de ces choix, je ne vais pas vous dire que ça va être nul ;) Il y a du contenu intéressant avec des intervenants qu'on n'a pas trop l'habitude d'avoir à portée de main en Europe.

Comme je le disais plus haut, si vous voulez faire un saut à Barcelone pour SOURCE, vous pourrez économiser 25% sur le prix de l'entrée en entrant le code CBSOURCE sur la page d'inscription.

Update (13/08/2010) : comme cela vient d'être noté en commentaire, ceux qui auront acheté une place pour BruCON juste après peuvent obtenir 50% de réduction avec le code SOURCEBru10.

PS : j'ai quelques photos en stock si ça peut vous donner envie ;)

icrosoft nous a offert hier la plus grosse livraison de l'histoire des Patch Tuesday. Jugez plutôt : pas moins de quatorze bulletins couvrant trente-quatre failles et un spectre de produits touchés plutôt sympa avec le kernel Windows, l'inévitable Internet Explorer, Office ou encore Silverlight. Quinze failles sont jugées critiques, huit d'entre elles étant gratifiées du XI maximum. Du côté des failles importantes, sept élévations de privilèges sont également jugées exploitables par l'éditeur.

Les paquets massifs de correctifs de ce tonneau ne manquent pas d'amplifier le problème classique du patch management. À savoir la prioritisation des déploiements. D'abord parce que le nombre de patches fait exploser les possibilités, et ensuite parce qu'une foultitude de scénarios d'attaque permettant d'obtenir des privilèges élevés à distance par combinaison s'offrent à l'attaquant.

Le déploiement des patches est un problème classique sur les systèmes de production. Selon le contexte, les priorités ne seront pas les mêmes : certains voudront patcher les failles les plus critiques en premier, d'autres préféreront préserver leur disponibilité en se jettant sur les patches qui ne nécessitent pas de reboot, quelques uns ne patcheront pas pour ne pas froisser des applicatifs métier chatouilleux. Sans compter ceux qui voudront commencer par celles présentant le plus grosse risque d'exploitation, même si ce dernier critère est quelque peu subjectif, donc parfois mal apprécié. Mais il faut bien commencer quelque part, me répondra-t-on. Sans parler des critères spécifiques à l'environnement. Etc...

Autant d'approches qui ne manquent pas de donner presque toutes les combinaisons de déploiement possibles et imaginables. L'exercice, combiné aux tests de validation, peut déjà se montrer lourd sur une dizaine de correctifs. Autant dire que sur une trentaine, ça commence vite à ressembler au passage de la Bérézina, en particulier quand Murphy s'en mêle ou quand vous devez croiser ça avec la livraison d'un autre éditeur. En fait, je pense qu'il arrive probablement un moment où il est probablement plus efficace de ne pas se poser la moindre question et croiser les doigts ;)

L'autre point, c'est que plus on a de vulnérabilités annoncées, plus on a de scénarios d'attaque potentiellement utilisables tant que tout n'est pas réglé. Ici, comme je le disais précédemment, parmi les seules failles jugées hautement exploitables par Microsoft, on trouvera huit exécutions distantes de code et sept élévations de privilèges. Soit un nombre conséquent de possibilités de mat en deux coups, à commencer par la fameuse faille LNK qui fait les titres depuis la semaine dernière. Ce qui ne manquera pas non plus d'influer sur l'établissement des priorités !

Ceux qui aiment les timelines record, les chiffres à slideware et autres anecdotes à sortir entre deux verres ne manqueront pas, comme Kostya, de s'intéresser à la dernière faille du bulletin MS10-048. Il trouverait son origine dans un bug remonté il y a... trois ans et demi... mais jamais pris en compte...

a France semble vouloir bouder l'ère numérique. Quand elle ne s'est pas mise en tête de déclarer la guerre à ce truc étrange que d'aucuns appellent l'Internet. Comme avec HADOPI typiquement. Et ce n'est que maintenant que Jiwa ferme ses portes que certains commencent à percuter que le cap n'est peut-être pas le bon. En attendant, les premiers dégâts sont faits et le train est lancé.

Malgré la mise en place d'un secrétariat d'état chargé de creuser la question, même les plus optimistes retiendront que rien n'a été fait en France pour favoriser le développement d'une économie numérique. Les autres avanceront que la politique mise en place ces dernières années n'a fait qu'enfoncer l'un après l'autre les clous du cercueil, en matière culturelle en particulier.

La disparition de Jiwa, c'est la mort du d'un des derniers acteurs indépendants français de la musique en ligne, après la main mise d'Orange sur Deezer. D'aucuns noteront qu'il reste Spotify, mais outre le déficit presque chronique de la boîte, elle n'est pas domiciliée sur le territoire. La cause de cette fermeture ? L'impossible satisfaction des conditions ubuesques imposées par les majors, qu'il s'agisse du ticket d'accès au catalogue ou de la rémunération à la lecture. Ce qui poussait les fondateurs de Jiwa à déclarer dès janvier dernier que "les conditions commerciales imposées par les majors font qu'aucun business de musique sur Internet n'est viable"...

Je ne vais pas épiloguer là-dessus, d'autant que Fabrice Épelboin s'est fendu d'un excellent billet sur la question. Mais j'en retire une citation qu'il rapporte de la part d'un utilisateur de Jiwa, directeur du département Internet d'un grand groupe de média :

Puisque c'est comme ça, je vais reprendre mes habitudes et 
pirater des mp3, hors de question de nourrir ces gorets

Et c'est ce qui à mon avis résume bien ce qui est en train de se passer en France. À trop caresser les majors dans le sens du poil avec des DADVSI et autres HADOPI, on étrangle d'une main les seules offres légales nationales dignes de ce nom pendant qu'on pousse de l'autre les utilisateurs vers un marché parallèle. Illégal, forcément. Et ce, qu'il s'agisse de musique ou de cinéma. Car ce n'est pas avec une Carte Musique Jeune à deux-cent euros ou en vendant de la VOD à cinq euros le titre HD pour 24h qu'on va attirer le chaland. En particulier lorsqu'il peut se fournir à volonté sur un tracker privé via un VPN anonymisant, le tout pour la modique somme d'une quinzaine d'euros par mois. Parce qu'aujourd'hui, les seuls à qui profite la situation, ce sont bel et bien ceux qui font tourner ces plate-formes de téléchargement illégal. Avec un costard de Robin des Bois sur mesure en prime. Et ce ne sont pas les folles aventures de Wawa Mania qui viendront me contredire...

Certes, Nathalie Kosciusko-Morizet s'indigne à présent de la situation d'asymétrie de marché que vit la diffusion musicale en ligne. Mais cette dernière n'est que la conséquence naturelle de la politique menée jusqu'alors et sur laquelle elle n'a jamais, à ma connaissance, émis la moindre réserve. Or, à taper sur le consommateur et à renforcer les majors dans leurs positions sans jamais rien leur demander en retour, j'ai du mal à voir à quel autre résultat on pouvait raisonnablement s'attendre. Et la réaction de la SCPP^[1] aux propos de NKM ne laisse pas présager que les choses évoluent positivement...

Même si le discours de la secrétaire d'état, qui doit mettre du baume au cœur des dirigeants de Jiwa j'en suis sûr, est intéressant et pleins de bonnes intentions, il reste encore à voir s'il sera suivi des faits... Et si ceux-ci n'arriveront pas trop tard^[2]... Je retiendrai néanmoins cette phrase :

pour que la loi Hadopi trouve tout son sens, il faut qu'il
y ai une offre légale de qualité en face qui soit vraiment 
attractive, et c'est vrai qu'aujourd'hui on peine à la
développer

C'est, pour le moins, un doux euphémisme...

Je ne veux pas entrer dans les réflexions sur d'HADOPI, son sens pour autant qu'elle en ait, sa mise en œuvre prématurément à l'existence du contexte qu'elle nécessite, comme l'existence des moyens de sécurisation ou de l'offre légale suscitée. Mais globalement, ce qu'on voit se profiler à l'horizon, c'est la disparition à court terme de l'offre française du paysage culturel numérique au profit des géants étrangers du marché, Apple en tête avec sa plate-forme iTunes. Oui Apple. Celui à qui on n'a même pas été foutu d'imposer une clause d'interopérabilité quand il menaçait de déserter le marché national. Dans ces conditions, j'ai hâte de voir comment va se porter la célèbre exception culturelle française sur un marché dominé par des acteurs de cet acabit.

En tout cas, si on aime l'exception culturelle en France, on n'a pas la culture de l'exception. Fin 2005, à l'occasion des débats autour du DADVSI, on avait eu la formidable opportunité de prendre une position unique et novatrice en adoptant la licence globale. Mais ce ne fut pas le cas, on a préféré faire les moutons, et depuis, c'est un peu descente aux enfers...

Si HADOPI est un exemple flagrant d'échec, annoncé qui plus est, ce n'est malheureusement pas le seul... Ces dernières années ont été constellées d'incidents, plus ou moins graves et/ou comiques, qui montrent bien combien ce pays traîne les pieds quand il s'agit entrer dans l'ère numérique tellement sa classe dirigeante semble ne rien (vouloir) y comprendre. Qu'il s'agisse de faire son technophile en déployant de la machine à voter, de produire du lipdub calamiteux, de porter atteinte aux droits d'auteur quand on s'en fait soi-même le chantre, de lancer des campagnes stériles à la Facebook à plusieurs centaines de milliers d'euros, de mettre en ligne des sites de campagne du siècle dernier, de prôner le filtrage du net sous prétexte de lutte contre la pédopornographique, de vouloir interdir l'anonymat sur le net pour régler ses propres déboires ou d'espérer du service public qu'il donne l'exemple de l'interopérabilité, il n'y en a pas un pour rattraper l'autre...

Et je n'ai même pas envie de m'étendre sur le tristement célèbre site France.fr qui, du haut de ses 1,6 millions d'euros et sa dizaine de serveurs, s'est montré incapable d'absorber ses cinquante-mille premiers visiteurs^[3]. Presqu'un mois plus tard, il ne s'en est toujours pas remis... On en rigole encore de l'autre côté de l'Atlantique...

Bref, il y a quelque chose qui ne tourne pas rond dans ce pays quand il s'agit d'embrasser Internet ou d'encourager le développement d'une véritable économie numérique. Le côté positif de cette approche cependant, c'est qu'en continuant sur cette voie, ça permettra de maîtriser les budget de cyberdéfense... En limitant les intérêts français à défendre sur le net...