Record battu: Microsoft vient de corrigé une faille vielle de 18 ans

Le , par imikado, Rédacteur
Microsoft corrigeait hier, via son traditionnel Pacth Tuesday, une faille permettait de prendre le contrôle de l'ordinateur en navigant avec Internet Explorer.

Le patch de sécurité corrige la faille pour les versions :
  • Windows server : 2003, 2008 et 2012
  • Grand public : Windows Vista, 7, 8 et 8.1
  • Tablette : Windows RT


Windows XP, n’étant plus supporté par Microsoft depuis avril dernier, n’a pas droit à un correctif, tout comme les autres versions non supportées de l’OS de Microsoft.

L'équipe de chercheurs d'IBM à l'origine de la découverte ont estimé que celle-ci était exploitable depuis Windows 95, soit 19 ans.

La faille repose sur un bogue dans VBScript, un sous-ensemble de Visual Basic utilisé en tant que langage de script d'usage général, qui avait été introduit dans Internet Explorer 3.0.

Aucune preuve de son exploitation par des pirates n’a été relevée. Selon les chercheurs d’IBM l’utilisation de la faille par un pirate serait assez difficile.

Selon Microsoft, le patch de sécurité a déjà été appliqué si vous utilisez les mises à jour automatiques (Windows Update).

Source: IBM

Que pensez-vous de ces failles très anciennes découvertes seulement aujourd'hui ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de sazearte sazearte - Membre expert http://www.developpez.com
le 13/11/2014 à 15:46
Se sujet m’intéresse
"La faille repose sur un bogue dans VBScript, un sous-ensemble de Visual Basic utilisé en tant que langage de script d'usage général, qui avait été introduit dans Internet Explorer 3.0."

Quelqu'un a un site pour en apprendre plus ?

Développant encore des activeX pour IE6, j'utilise pas mal en VBScript et j'aurais aimée en connaitre d'avantage sur ce bogue.
Avatar de herve4 herve4 - Membre habitué http://www.developpez.com
le 13/11/2014 à 16:19
et c'est ainsi que la NSA a pu introduire un backdoor pour contrôler tout les OS de Windows ...

Tant pis je vais passer au DOS 3.1
Avatar de rt15 rt15 - Membre confirmé http://www.developpez.com
le 13/11/2014 à 17:23
Citation Envoyé par sazearte  Voir le message
Développant encore des activeX pour IE6, j'utilise pas mal en VBScript et j'aurais aimée en connaitre d'avantage sur ce bogue.

Des explications sont données dans la source de l'article.

En deux mots le souci a lieu lors de l'appel de "redim preserve" qui permet de redimenssionner un tableau dynamique en VB. Ce redimenssionement est géré par la fonction SafeArrayRedim de OleAut32.dll.

Lors de l'appel à cette fonction, la taille demandée est settée dans le tableau rapidement.
Mais dans le cas d'une erreur bien précise (Un échec d'allocation visiblement), la taille du tableau n'est pas settée à la taille initiale.

Donc si "on error resume next" est utilisé (Cela permet de continuer l'exécution du VB même si une erreur se produit), on se retrouve avec un tableau dynamique qui pense avoir une taille différente de sa taille réelle.
Et donc on peut taper en mémoire un peu n'importe où.

Par exemple on créé un tableau de 5 éléments.
On fait un redim preserve à 2000 éléments qui foire avec la bonne erreur.
Et on se retrouve avec un tableau de 2000 éléments, avec les 5 permiers qui sont des vrais éléments et les 1995 qui correspondent à la mémoire qui se trouve après le tableau de 5. On peut donc lire et écrire hors du tableau physique : "array(1900) = 2" sans que VB ne remarque de problème, car il demande la taille au tableau qui lui répond 2000.

Un problème dans l'exploitation de cette faille est que les éléments font 16 octets : 4 octets pour le type de variant, un padding de 4 octets, 8 octetd de données (Par exemple un double ou un currency). Et logiquement, en VB, on ne peut vraiment modifier directement que les 8 octets de données, donc on a un peu accès à la mémoire par petit morceau.
Mais bon il semble qu'il y ait des solutions pour avoir plus de contrôle notamment si on arrive à avoir deux tableaux décalés de 8 octets ce qui donne plus ou moins accès à tout.

Quand on a un accès arbitraire à la mémoire, on fait un peu ce qu'on veut en théorie. L'exécution de code à distance devient enviseagable. Dans le cas du VB, il y a proposition de remplacer VT_DISPATCH ou VT_UKNOWN par une autre implémentation.
Avatar de sazearte sazearte - Membre expert http://www.developpez.com
le 13/11/2014 à 18:16
Ok merci pour ces explication
Avatar de miky55 miky55 - Membre averti http://www.developpez.com
le 13/11/2014 à 22:02
Des failles vieilles de 20 ans il doit en exister des dizaines sur à peu près toutes les plateformes. Mais une faille commence réellement à exister quant elle a été découverte.
Est-il possible que cette faille n'ai été découverte (un exploit réalisé) que après tant d'année? Oui.

Cette faille exploitant une vulnérabilité vbscript il est plutôt facile de trouver des exploits s'il en existe: un bot qui parcourt le web et analyse tout code vbscript disponible devrait faire l'affaire...
Avatar de MilWolf MilWolf - Membre à l'essai http://www.developpez.com
le 16/11/2014 à 1:50
Avatar de marsupial marsupial - Membre éclairé http://www.developpez.com
le 16/11/2014 à 14:55
Pour moi, elle a été exploitée une fois un jour de Septembre du début du millénaire. Si ce n'est elle, il s'agit de sa soeur.
Avatar de Médinoc Médinoc - Expert éminent sénior http://www.developpez.com
le 16/11/2014 à 16:15
Si j'ai bien compris, le bug était dans la fonction SafeArrayRedim() elle-même, et non dans VB.
Ce qui constitue un bug pour tout code utilisant la fonction, mais ne constitue une faille de sécurité proprement dite que pour des langages interprétés utilisant SAFEARRAY car il peut autoriser des accès arbitraires à la mémoire que le langage interprété ne permettrait pas normalement.
Avatar de Pierre GIRARD Pierre GIRARD - Expert confirmé http://www.developpez.com
le 20/11/2014 à 14:29
Citation Envoyé par Shuty  Voir le message
Et uuuuune raison de plus de laissé son bon vieux XP de côté...

Même pas, si j'ai bien compris, c'est une faille liée d'une part à Visualbasic, d'autre part à IE. Comme je n'utilise pas IE, et encore moins Visualbasic, pas sur que mon XP craigne quoi que ce soit.
Avatar de Médinoc Médinoc - Expert éminent sénior http://www.developpez.com
le 20/11/2014 à 14:45
Beaucoup d'applications sont "hôtes" d'un IE, et une page web peut contenir du code VBScript, dont l'activation pourrait bien reposer sur la même case à cocher que Javascript...
Avatar de Pierre GIRARD Pierre GIRARD - Expert confirmé http://www.developpez.com
le 20/11/2014 à 17:58
Citation Envoyé par Médinoc  Voir le message
Beaucoup d'applications sont "hôtes" d'un IE, et une page web peut contenir du code VBScript, dont l'activation pourrait bien reposer sur la même case à cocher que Javascript...

Je continue à ne pas être inquiet.
Offres d'emploi IT
Développeur - software craftsman (H/F)
Société Générale - Ile de France - Hauts-de-Seine
Analyste SI-métier (H/F)
Société Générale - Ile de France - Val-de-Marne
Technical leader / moe perle (H/F)
Société Générale - Ile de France - Val de Marne

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Windows