IE

C’est une réflexion en cours dans de nombreuses entreprises cette année : “Devons nous passer à Windows 7 ? Si oui, quand et quels seront les problèmes potentiels liés à la migration ?”.

Et dans les éléments à prendre en compte, le navigateur n’est pas le moins important. Il est vrai que d’un coté, Microsoft explique que la version 8 de son Internet Explorer est “plus sûre, plus rapide et plus simple que jamais”… sous entendu que les versions 6 et 7. Mais d’un autre coté, bon nombre d’applications web en entreprise nécessitent encore IE6. Ce sont parfois des applications qui ont été développées en interne, ou par un prestataire externe, elle ne sont plus forcément supportées et en tout cas, le passage des postes de l’entreprise en Windows 7 (et donc en IE8) pose question.

Doit-on faire évoluer ces applications compatible IE6 pour permettre aux utilisateur de s’y connecter avec IE8 ? Est-ce possible ? Combien ça coûte ? Et quelle est la pérennité de ce choix ?

Il y aura forcément des versions de IE après la version 8. Il y aura aussi de nouveaux navigateurs et de nouveaux terminaux (pourquoi pas quelques Mac et quelques smartphones ?). Fatalement, il faudra à nouveau supporter ces navigateurs et donc intervenir sans cesse sur ces applications pour les mettre à jour. A moins que…

A moins qu’une alternative beaucoup plus intéressante économiquement et beaucoup plus pérenne soit possible. Il faudrait pouvoir laisser ces applications en l’état (donc compatibles IE6) et permettre aux utilisateurs d’utiliser indifféremment IE6 et IE8 depuis leur poste Windows 7. C’est précisément ce que permet Virtual Browser.

En effet, avec Virtual Browser, vous pouvez migrer vos postes sur Windows 7 et virtualiser IE6 (et pourquoi pas d’autres navigateurs ?) pour permettre à vos utilisateurs de continuer à accéder aux applications compatibles avec ce navigateur.

L’idée est d’isoler le bon navigateur et les bons plugins (flash, java, …) dans une bulle virtuelle du serveur Virtual Browser. Cette bulle, montée à la volée et unique pour chaque utilisateur, est dédiée à la connexion vers la (ou les) application(s) nécessitant cette configuration de browser. Pour en savoir plus, consultez le témoignage d’un utilisateur.

En début de semaine, une nouvelle vulnérabilité dans IE6 et IE7 a été rendue publique sur Internet avant que Microsoft n’en ai eu connaissance. Ce dernier a réagi avec un bulletin de sécurité mais n’a pas encore donné de date pour un correctif. Comme d’habitude (souvenez-vous de ça, ou de ça), les moyens de protection sont relativement contraignants et les risques assez elevés (accés au poste avec les droits de l’utilisateur). Cela risque de poser problème si une attaque d’envergure est mise en place à court terme car ce sont des navigateurs utilisés en forte proportion en entreprise.

Il n’est jamais trop tard pour rappeler qu’une attaque web peut tromper même le plus averti des utilisateurs. C’est ce qui vient d’ailleurs d’arriver à Gadri Evron (expert reconnu en sécurité) qui a participé à son insu à propager un ver sur Facebook. Même si celui-ci a été rapidement stoppé par Facebook, il est intéressant de noter que le ver utilisait la technique du Clickjacking (et non une vulnérabilité CSRF comme indiqué initialement sur certains blogs) pour se propager.

La plupart des navigateurs sont impactés par des problèmes de sécurité en ce début de mois de Juillet.

• Après la vulnérabilité dans le composant Video Control qui n’est toujours pas corrigée par Microsoft, c’est au tour du composant Office Web Components Control d’être activement exploité sur Internet pour prendre le contrôle d’Internet Explorer… [Microsoft Security Advisory 973472]
• Mozilla a publié très rapidement une version 3.5.1 de Firefox pour corriger une vulnérabilité critique dans le moteur Javascript pouvant permettre l’execution de code. Depuis, une nouvelle vulnérabilité a été découverte mais Mozilla se défend en indiquant qu’elle n’est pas exploitable, il s’agit juste d’une vulnérabilité DoS…
• Google prend les devants en sortant une version 2.0.172.37 de Google Chrome qui corrige deux vulnérabilités critiques découvertes en interne (et donc pas encore publiques). Sur les deux vulnérabilités, la technologie de sandbox mise en avant par Google ne permet de minimiser l’impact que d’une seule…
• Apple a corrigé deux vulnérabilités critiques dans Safari 4.0.2 : possibilité de cross-site scripting, déni de service et execution de code…

Il y a quelques mois, Window Snyder (responsable sécurité pour Mozilla Corporation) déclarait dans une interview pour Computerworld qu’il était impossible de construire un navigateur sans aucune faille de sécurité. Il suffit de parcourir le Browser Security Handbook publié il y a quelques jours par Google pour s’apercevoir que la tâche n’est effectivement pas simple. Si on rajoute à cela la nécessité de supporter de plus en plus de format de fichiers, les sources de vulnérabilités potentielles sont nombreuses.

« It’s impossible to build a perfectly secure browser » — Window Snyder

Microsoft est d’ailleurs en train de s’en rendre compte avec une vulnérabilité critique dans IE (dont websense a fait une excellente analyse) qui commence à être activement exploitée afin d’infecter les machines Windows. Habilement sortie en même temps que le patch Tuesday de Décembre, la vulnérabilité risque de faire beaucoup de dégâts avant même que Microsoft ne déploie un correctif, d’autant que les solutions de contournement ne sont pas simples à mettre en œuvre. Pour faire face à cela, Microsoft devrait sortir un correctif en dehors de son cycle habituel dans la journée.

Tout cela met en évidence le fait qu’il est nécessaire de pouvoir restreindre au maximum les conséquences d’une exploitation qui finira fatalement par arriver. Une des solutions est d’isoler le navigateur dans un environnement virtualisé afin d’éviter la prise de controle du poste par un virus.