Faille IE : Microsoft remet en cause la conception du logiciel

Si Microsoft a « oublié » dans ses processus de développement le très sérieux bogue XML d'Internet Explorer, c'est bien parce que ses équipes ne sont pas préparées à ce type de faille.
L'éditeur de Redmond, quelques jours après avoir publié dans l'urgence le correctif de la faille ayant contaminé plusieurs milliers de site Web, revient sur le déroulement des procédures de sécurité dans les phases de développement. Presqu'une excuse au reste du monde, exprimée par Michael Howard, spécialiste en sécurité chez Microsoft, sur son blog.

Le 9 décembre, une faille Zero-Day dans Internet Explorer 7 a été repérée par différents organismes de sécurité et classée d'emblée comme très critique. La première émanation proviendrait de Chine. Sans rustine adéquate, le Cheval de Troie, que la faille permet d'injecter, a commencé à se propager à vitesse grand V. Un état d'urgence pour le monde entier, d'autant qu'on apprend que la faille en question touche toutes les versions du navigateurs de Microsoft. L'éditeur se décide à publier le sacro-saint correctif le 18 décembre, en dehors de son Patch Tuesday.

C'est donc cinq jours à peine après ce climat d'urgence que Michael Howard explique que la faille de part sa nature particulière – on parle de bogue "time-of-check-time-of-use (TOCTOU) – n'est pas prise en compte dans les procédures sécuritaires des équipes de développement Microsoft. Selon Wikipedia, un bogue TOCTOU est causé lors de modifications du système entre les phases d'association de données (data binding). Par exemple, entre la vérification d'une condition et l'exploitation des résultats de cette même vérification.
Michael Howard explique ainsi que « les bogues TOCTOU liés à la mémoire sont difficiles à identifier dans la vérification du code; nous formons [les développeurs, NDLR] aux problématiques de TOCTOU, et nous enseignons les problèmes de corruption de mémoires […], mais nous ne les informons pas sur les bogues TOCTOU liés à la mémoire ». Tout en précisant que les équipes seront désormais entrainées à cela.

Selon lui, il apparaît également que les outils de tests utilisés sont restés inefficaces, et n'ont pas repéré le bogue en question. « Nos outils d'analyse statique ne l'ont pas identifié parce qu'il aurait fallu qu'ils comprennent la nature asymétrique du code », précise-t-il. Même si les tests d'injections de données ad-lib (Fuzz Testing) permettent en théorie de réaliser ce genre de prouesse, ce bogue serait resté invisible, insiste Michael Howard.

Rien à faire semble-t-il certifier, d'autant que si des remparts existent dans Vista et Windows Server, comme les technologies ALSR (Address Space Layout Randomization – modifie dynamiquement l'emplacement de la mémoire) et NX (No eXecute – contre le « buffer overflow »), ils ne sont pas activés par défaut dans IE pour des raisons d'incompatibilités. Seul le Protected Mode d'IE constitue la parade pour ce bogue. Ce qui lui fait dire que « vous ne pourrez jamais obtenir du code fiable à 100%, il faut alors multiplier les moyens de défense».

Un dernier point qui pousse Michael Howard à tirer des conclusions de cet épisode. « [...] Il est nécessaire que, nous, l'industrie du logiciel, travaillons plus dur pour s'assurer que les applications exploitent les défenses proposées par Windows aujourd'hui ».  Et également revoir les cycle de vie des développements.