On a beaucoup parlé début juillet de la faille DNS annoncée par Dan Kaminsky sans le moindre détail technique, la révélation de ces derniers ayant été annoncée pour Black Hat US. Prétexte : il faut laisser du temps pour patcher, sinon, ça va être la fin du monde. Ce qui n'a pas empêché les curieux de découvrir assez rapidement de quoi il retournait, pendant que les gens en charge de vrais systèmes s'arrachaient les cheveux au jeu du "patchera, patchera pas". Situation frustrante pour beaucoup, clairement motivée par un énorme coup de pub pour son talk, mais au moins avait-il eu la décence d'attendre la disponiblité de correctifs pour faire son coming out. Et de révéler les détails lors d'une intervention jugée assez décevante par beaucoup. Bref, de s'en tenir à son planning.

Le cas de Robert E. Lee et Jack C. Louis est quelque peu différent, puisqu'eux ne vont pas tenir leurs engagements. Non content de nous annoncer la fin du monde et de faire de la pub pour T2 et leur talk sur le dos de la bête, ils arrivent sans aucun patch d'aucune sorte, s'abritant derrière de belles louanges du full disclosure comme moteur dans la recherche de mesures de corrections efficaces. Donc promis juré, à T2, on vous dira tout et on pourra tous s'atteler à la résolution du problème.

This talk will divulge new technical details about Outpost24s
(Jack C. Louis) research into TCP state table manipulation
vulnerabilities that affect availability.

Sauf que non. On n'en apprendra pas plus que ce qui a été diffusé à Sec-T. Vous comprenez, c'est trop dangereux, laissons le CERT-FI gérer la crise et allons signer les autographes.

Troisième fin du monde annoncée sur la liste, l'exploitation distante de bug CPU par Kris Kapersky à HITB. Contrairement aux deux autres, très peu de pub autour de ce talk, cependant assez attendu par les curieux que nous sommes. Et là, je vous le donne en mille : rebelote ! Rien !... Vous comprenez, trop critique, va tout casser. On restera songeur en relisant le teaser de la présentation :

In this presentation, I will share with the participants the
finding of my CPU malware detection research which was funded
by Endeavor Security. I will also present to the participants
my improved POC code and will show participants how it's
possible to make an attack via JavaScript code or just TCP/IP
packets storms against Intel based machine.
[...]
I will also share with the participants my experience in data
recovery and how CPU bugs have actually contributed in
damaging our hard drives without our knowledge.

Point de détail, point de preuve de concept, point d'histoire de disques durs[1], même pas de démo apparemment.... Rien que du réchauffé : les CPUs et leur documentation ont des bugs, et ces bugs peuvent être exploités. Et devinez quoi ? Ben si vous avez une application qui écoute sur le réseau, vous pourriez bien les exploiter à distance. Ah non mais là, je suis scié. Y'a du prix Nobel qui se perd là. De la vraie nouveauté...

En gros, cette présentation, c'est ce que j'appelle un gros pêtard mouillé. Non que je conteste l'originalité des travaux qui, peut-être, sont derrière. Mais avec un tel écart entre le contenu annoncée et celui présenté, il aurait probablement mieux fait de s'abstenir. Surtout pour nous sortir des énormités du genre "Newer CPUs have fewer bugs", avec des centaines de bugs sur des processeurs récents. À comparer avec quoi ? Près de dix ans de Pentium III ou IV ? Bref...


Mais trève de sarcasmes.

Ce qui me gêne là-dedans, c'est qu'il y a là une tendance qui commence à s'implanter très sérieusement dans un paysage déjà sujet à pas mal de critiques plus ou moins justifiées. Et si les conférences de sécurité se transforment en une longue série de "je peux pas vous dire, trop dangereux", autant arrêter les frais. Mais plus loin que les joutes oratoires sur la qualité des orateurs ou la pertinence de leurs interventions, ce n'est pas tant à l'encontre des auteurs de ces soufflets dégonflés que va mon agacement, mais surtout envers les organisateurs de ces conférences.

Car en acceptant ce genre de comportement, ils cautionnent ce qui me semble être un manque de respect flagrant à l'encontre de leur auditoire. Avec à la clé la perte de toute crédibilité. Alors que faire ? Vaste question. Si on n'est jamais à l'abri d'un mauvais talk, d'une description ambigüe qui fait espérer, bref de quelque chose qui n'est pas à la hauteur des attentes, on peut tout de même s'attacher à faire en sorte que les speakers tiennent un minimum leurs promesses. Avec des moyens comme cette idée qui vient très vite en tête, à savoir la déprogrammation du speaker. En effet, si la nouvelle version du talk ne présente plus aucun intérêt, pourquoi le maintenir ?

À Pacsec 2004 par exemple, Ejovi Nuwere était programmé avec un talk sur l'audit d'un réseau gouvernemental japonais. S'étant vu interdit la diffusion de l'essentiel de son contenu, il avait préféré, en accord avec les organisateurs, renoncer à son intervention plutôt que de se livrer à une présentation sans intérêt, laissant sa place au speaker de secours. N'aurait-il pas été judicieux de faire la même chose à T2 pour Outpost ? Ou pour Kris Kasperky à HITB ? La réponse n'est clairement pas évidente, mais la question mérite certainement d'être posée...

En tout cas, il est temps que ça change...

Notes

[1] En tout cas dans les slides...