Magazine High tech

Ormandy vs. Sophos, second round...

Publié le 06 novembre 2012 par Sid

Red Sophos logo

U

n peu plus d'un an après un premier papier incendiaire à l'endroit de l'antivirus de l'éditeur Sophos, Tavis Ormandy remet le couvert avec un advisory sur Full-Disclosure aux conclusions dures et sans appel, accompagné d'un papier détaillé, d'une exploitation sous MacOS et d'une série de PoCs démontrant les failles remontées.

Du côté de chez Sophos, on se félicite du travail accompli avec le chercheur, lequel ne semble pas complètement partager ce point de vue quand il parle de, je cite, "substandard security" s'agissant des produits de l'éditeur ou le qualifie de "ill-equipped to handle the output of one co-operative, non-adversarial security researcher" s'agissant de sa capacité de réaction...

Je ne discuterai pas ici les vulnérabilités présentées par Tavis Ormandy dans la mesure où le bulletin de l'US-CERT et son papier constituent des lectures suffisamment éclairantes à ce propos. Je préfère m'en tenir à une mise en perspective de cette annonce avec celle qui l'a précédée.

L'an dernier, Tavis Ormandy présentait à Black Hat ce qui s'apparentait à une volée de bois vert à l'encontre de l'antivirus Sophos. Dans ce papier, il mettait en exergue la faiblesse de certaines signatures, une protection contre les buffers overflow, BOPS[1], défaillante, un algorithme de chiffrement propriétaire faible, une émulation contournable et une surface d'attaque bien trop grande. Cette fois, le chercheur enfonce le clou en démontrant par la pratique certaines de ses affirmations, expliquant combien l'utilisation de ce produit rend le système supposément protégée encore plus vulnérable qu'elle ne l'était sans. Un comble pour un produit de sécurité.

Car en plus de failles d'implémentations susceptibles d'être exploitées, comme un integer overflow dans le traitement du code VB6 ou un stack overflow dans le déchiffrement des PDF, il est démontré comment la mise en œuvre de la simili-protection BOPS désactive purement et simplement l'ASLR fourni nativement par Windows, comment l'outil désactive le mode protégé d'Internet Explorer et la Same Origin Policy des navigateurs, ou encore comment le produit permet une escalade de privilège via son service de mise à jour.
En outre, Tavis Ormandy annonce d'ors et déjà un troisième papier sur le produit, et un nouveau lot de failles dont les correctifs sont annoncés pour la fin du mois.

Autant de faits qui font que la réponse de Sophos se fait nettement plus timide que la dernière fois, se bornant à confirmer les failles, annoncer la disponibilité des patches et nous faire une démonstration certes éloquente mais malheureusement affreusement banale de réponse pipeau en trois actes.
Acte premier, "nous $vendor nous sentons responsable de la sécurité de nos clients et c'est pourquoi nous accordons la plus grande importance à ce genre de travail". Acte second, "notre $product a des failles, mais les patches sont là et, rassurez-vous chers clients, nous n'en avons vu aucune exploitation dans la nature[2]". Troisième et dernier acte, "nous $vendor remercions profondément $researcher pour le travail qu'il a fourni qui nous aide à améliorer la sécurité de $product".

Si on pouvait en appeler au bénéfice du doute la première fois, ce n'est plus le cas maintenant. Et c'est justement parce que ce premier coup de semonce ne semble pas avoir franchement été suivi d'effet, que, en l'absence de faits concrets pour l'appuyer, la réponse de l'éditeur sonne creux. En effet, si sa priorité était effectivement la sécurité de ses clients, on imagine alors qu'il aurait à cœur de leur fournir un produit efficace et de qualité. Et aurait donc tiré quelques enseignements du premier rapport et, par exemple, n'utiliserait plus BOPS sur les systèmes fournissant de l'ALSR nativement[3]. Il accorderait plus d'importance à la qualité de son code, se soucierait de son évaluation, et se ferait fort d'utiliser des techniques de protection contre l'exploitation largement répandues[4]. Choses qui n'ont apparemment pas été faites et qui amènent Ormandy à prévenir : "if Sophos do not urgently improve their security posture, their continued deployment causes significant risk to global networks and infrastructure". Voire à recommander la migration vers un autre produit[5] le cas échéant.
De plus, si l'éditeur mettait effectivement un point d'honneur à réagir efficacement à ce type de remontées, on imagine également qu'il aurait, depuis la dernière fois, sensiblement amélioré sa capacité à le faire. Or ça ne semble pas être le cas non plus, puisqu'il est indiqué dans les recommandations finales que "Sophos cannot react quickly to reports of vulnerabilities in their products, even when presented with working exploits".

Bref, en somme et pour reprendre certains griefs déjà exprimés à l'encontre des éditeurs, il aurait agi en conséquence et ne donnerait pas l'impression de compter sur les autres pour assurer gratuitement son assurance qualité. Griefs qui, rappelons-le, ont donné lieu à des initiatives pas forcément heureuses par le passé. Initiatives que Sophos serait plus inspiré, à mon humble avis, de ne pas encourager plutôt que simplement les fustiger...

Si les conclusions de Tavis Ormandy sont particulièrement dures[6], il ne faut pas oublier que l'antivirus de Sophos est un produit parmi beaucoup d'autres. Et donc ne pas perdre de vue qu'à ce titre, et en l'absence de travaux comparatifs similaires sur les solutions d'autres éditeurs, il n'y a guère de raison de penser que leurs antivirus respectifs fassent forcément meilleure impression en la matière.

"Quis custodiet ipsos custodes" ?

Ce qui devrait également nous amener, si ce n'est déjà fait, à nous interroger non pas sur l'efficacité régulièrement critiquée de ces produits souvent considérés comme une des dernières lignes de défense, mais tout simplement sur leur sécurité intrinsèque. Et à mettre en balance l'étendue de la menace qu'ils font planer sur nos infrastructure au regard du service rendu, et des moyens dont nous disposons pour nous en protéger efficacement...

Notes

[1] Buffer Overflow Protection System.

[2] Ça l'air d'être le plus important, c'est en gras dans l'advisory. Mais passons...

[3] Voire ne l'utiliserait plus du tout, au profit d'une solution plus efficace dans les autres cas.

[4] /GS typiquement...

[5] Dont on imagine qu'elle a été évaluée par ses soins...

[6] Voir la partie "Best practices" du papier.


Retour à La Une de Logo Paperblog

A propos de l’auteur


Sid 341 partages Voir son profil
Voir son blog

l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte