jeudi 21 janvier 2010

Aurora FAIL

Je ne vais pas faire l'insulte à mes lecteurs de revenir sur le déroulement de ce qu'il est convenu d'appeler "l'opération Aurora".

A peu près tous les vendeurs d'antivirus, de HIPS et de NIPS vous ont déjà sensibilisés au fait que leur produit aurait permis de bloquer cette attaque (sauf que les 30+ entreprises concernées - dont Symantec -disposaient déjà probablement de nombreux produits de sécurité actifs sur leur réseau, mais c'est un autre débat).

Au final, toute cette histoire aura été l'occasion d'un FUD considérable sur Internet, et d'une superbe opération de communication de la part de Google qui se pose en champion de la liberté.

FAIL#1 Ce qui me choque le plus, c'est qu'une société aussi innovante que Google soit à la merci d'une faille dans Internet Explorer 6. Moi qui pensait qu'ils utilisaient Chrome ;)

Compte-tenu de l'historique de sécurité d'Internet Explorer 6, et du nombre de failles "annexes" qui peuvent être déclenchées automatiquement par le biais de ce navigateur (tous les ActiveX et les codecs installés localement, ainsi que Acrobat Reader, Flash, ShockWave, QuickTime, RealPlayer ...), la conclusion évidente est que surfer sur Internet avec IE6 sans protection (ex. SandBoxIE ou au minimum DropMyRights) est juste parfait pour attraper le SIDA, la syphilis et la variole de l'informatique.

Toute entreprise dont la sécurité interne dépend directement de la sécurité d'IE6 est condamnée à l'infection. Avec le nombre de gens brillants en charge de la sécurité chez Google, j'aurais cru cette vérité comme évidente pour eux.

Personnellement, je ne sors plus qu'avec FireFox + NoScript, et encore je me méfie de la surface d'attaque offerte par le plugin NoScript lui-même ...

FAIL#2 "Les attaques proviennent de la Chine".

Dans le cas de Google, il est fort probable qu'il s'agisse d'un insider job depuis leur bureau en Chine. Toute personne qui a ouvert un bureau ou une usine en Chine sait que ce scénario est très crédible.

Mais quand on regarde le schéma global de toutes les attaques, très peu d'adresses IP sont effectivement situées en Chine. N'importe qui aurait pu faire l'acquisition de cette faille IE (comme il s'en vend plein sur Internet). Et la "sophistication" des attaques reste à démontrer ... car après tout il s'agit juste de déposer des exécutables sur le système de la victime, utilisant un protocole basé sur le chiffrement "XOR" avec une clé de 1 octet. N'importe quel pare-feu personnel devrait être capable de détecter ce type d'activité anormale.

Si vous êtes paranoïaque, il ne vous coûtera pas grand'chose de bloquer toutes les adresses IP chinoises sur votre réseau. Ainsi que tous les domaines de la forme "[0-9]+.{org|.net}" (par exemple, les domaines chinois 8800.org et 3322.net étant exclusivement connus pour héberger du malware).

FAIL#3 Data Execution Prevention (DEP)

Tous les problèmes de sécurité ont été résolus en même temps qu'ils sont apparus. Mais l'industrie s'est tout de suite confrontée aux problèmes, tandis que les solutions ont été beaucoup plus longues à faire leur chemin.

Ainsi au début des années 2000, le problème de la non-exécution de code dans les zones de données a été parfaitement résolu par PaX, mais ce patch n'a jamais été intégré dans le noyau Linux pour des histoires personnelles entre Linus et la PaX team.

Parmi les conditions de mise en oeuvre de la non-exécutabilité des données (DEP sous Windows), il est évident depuis le début que le positionnement des exécutables en mémoire doit également être aléatoire (ASLR), sinon il est possible d'utiliser une technique connue sous le nom de retour dans la libc.

Bref, tout le monde a spéculé sur l'efficacité de DEP pour protéger Internet Explorer. Outre le fait que les versions 6 et 7 n'utilisent pas DEP par défaut, cette protection est de toute façon inefficace sur Windows XP puisque le placement en mémoire des exécutables est prédictible (sauf à utiliser WehnTrust).

Le plus gênant dans cette affaire, ça n'est pas le fait que DEP puisse être contourné sous certaines conditions. C'est que personne n'a pris la peine de tester avec l'exploit public avant d'écrire tout et n'importe quoi.

FAIL#4 Secure Development Lifecycle (SDL)

Ce qui me semble extrêmement intéressant dans les dernières failles Internet Explorer et Acrobat Reader, c'est que les méthodes de développement sécurisé proposées par Microsoft (SDL) n'auraient pas permis de les éviter.

En effet, le SDL vise (entre autres) à bannir les API "dangereuses" (de type strcat() ou sprintf()) - c'est-à-dire à lutter contre les buffer overflows.

Or les failles dont on parle sont de type use after free. Par exemple dans le cas de la faille IE, celle-ci se résume à:

  1. Ajouter un évènement sur un objet du DOM
  2. Supprimer l'objet en accédant au DOM via JavaScript
  3. Attendre que l'évènement soit invoqué
Trivial, n'est-il pas ? Pourtant ces failles sont extrêmement difficiles à détecter, aussi bien en analyse statique qu'en analyse dynamique (fuzzing) que par une revue de code manuelle, surtout sur du code massivement multi-threadé.

On peut donc suspecter que le use after free va encore faire parler de lui ... et pas seulement dans Internet Explorer 6 !

Conclusion

L'affaire "Aurora" ne change rien à mes conclusions antérieures. Si vous avez des vrais problèmes de sécurité, prenez conseil auprès de vrais spécialistes. 95% de l'information disponible sur Internet est partielle, fausse ou non vérifiée.

8 commentaires:

Anonyme a dit…

>>>la non-exécution de code dans les zones de données a été parfaitement résolu par PaX, mais ce patch n'a jamais été intégré dans le noyau Linux pour des histoires personnelles entre Linus et la PaX team.

Des histoires personnelles ? Vraiment ?
Je serai très intéressé par un lien appuyant cette affirmation farfelue. Linus avait des objections techniques à faire valoir et pas des problèmes personnels avec les devs de PaX.
Voir http://thread.gmane.org/gmane.linux.kernel/774825/focus=774824 ou Linus reproche des trucs au code et reproche aussi le fait d'avoir un gros paquet non clairement séparé en diverses fonctions indépendantes.

Anonyme a dit…

Pourrait-on chercher un lien quelconque avec la toute nouvelle promotion d'un navigateur, plus rapide et plus sur... toute cette histoire pourrait-elle être une vaste fumisterie et un énorme coup marketing pour chrome?

Ce qui me surprend, outre le fait que google utilise IE et pas chrome, c'est que c'est la premiere fois qu on parle à ce point d'une faille de secu et pourtant c'est pas la premiere et loin de là sur IE...
Mais que CERTA ou meme le gouvernement francais recommande de ne plus utiliser ce navigateur là ca fait beaucoup je trouve... et c'est bien au dela de leurs prérogatives!

newsoft a dit…

@Linus fanboy: l'argument technique ne tient pas. S'il existait une réelle volonté d'intégrer une protection efficace dans le noyau, il aurait suffi d'un peu de bonne volonté pour "nettoyer" le patch.

En l'occurence Linux souffre périodiquement de NULL DEREF exploitables, faute d'avoir intégré le patch GrSecurity.

@Chrome hater: le CERTA ne recommande pas officiellement d'abandonner Internet Explorer. Voir le billet de Sid à ce sujet.

Anonyme a dit…

Ceci dit... C'est bien de relativiser et de remettre les points sur les "i" conçernant les techniques permettant de se prémunir.

Mais on ne peut pas dire, qu'a lire le bulletin a l'heure actuelle publié par Microsof "relativise".

Au contraire, on est passé à un niveau critique pour toutes les versions d'IE...

Bref, fail#1 n'en est plus tout à fait forçément un... les autres demeuren!

newsoft a dit…

MAJ#1 Le patch MS10-002 est finalement sorti et corrige ... 8 failles dont 6 de type use after free.

Je ne vois pas pourquoi on a fait tout un foin de ce "0day", sauf que cette fois-ci il a été utilisé pour autre chose qu'installer des scarewares !

Car des failles dans IE, il y en a eu, et il y en aura encore ...

MAJ#2 Je n'ai pas tous les détails de l'histoire, mais quand je lis ce récent message de la PaX team je sens quand même poindre de l'ironie envers les mainteneurs officiels du noyau ...

Anonyme a dit…

bon en même temps c'est normal que du IE traîne chez google.

ils doivent bien vérifier la compatibilité de leur site avec ce navigateur qui est encore dominant...

newsoft a dit…

Ah tiens, une nouvelle faille IE8 à vendre.

Plus les choses changent, plus elles restent les même ...

newsoft a dit…

Cela a peut être plus de poids si c'est un américain connu qui parle:

One Exploit Should Not Ruin Your Day

En tout cas, on est bien d'accord ...