Discussion :

[imikado]

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 ?

[Angelsafrania]

Comme quoi les veilles failles sont possible dans n'importe quel type de développement (ouvert ou fermé) (cf la faille shell bash présente depuis 22 ans).
C'est bien qu'on les voit, c'est mieux qu'on arrive à les détecter plus tôt avant la publication du produit.

Le problème avec les veilles faille c'est que beaucoup de plateforme doivent être patcher et ca prend beaucoup de temps, donc ca laisse pas mal de possibilité pour les pirates de se faire plaisir.

[Guikingone]

Mieux vaut tard que jamais, enfin, entre tard et 19 ans ...

[jmebula]

Une pareille faille découverte après toutes ces années! ça risquerait de remettre en cause la confiance en MS! mais d'autre part il est dit "vaut mieux tard que jamais"

[imikado]

Une pareille faille découverte après toutes ces années! ça risquerait de remettre en cause la confiance en MS! mais d'autre part il est dit "vaut mieux tard que jamais"

J'en suis pas sur, pour rappel, il y a quatre ans on avait trouvé une faille vieille de 17 ans...

Une faille de sécurité présente dans les codes de Windows depuis 1993 rend vulnérables toutes les versions 32 bits du système d’exploitation depuis Windows NT 3.1 jusqu’à Windows 7.

http://www.tomshardware.fr/articles/...ws,1-4270.html

[Shuty]

Et uuuuune raison de plus de laissé son bon vieux XP de côté...

[koyosama]

Et uuuuune raison de plus de laissé son bon vieux XP de côté...

Qui te dit qu'ils ont vraiment corriger une faille

[RyzenOC]

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.

[herve4]

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

[rt15]

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.

[RyzenOC]

Ok merci pour ces explication

[miky55]

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...

[MilWolf]

PLus d'infos : http://www.exploit-db.com/exploits/35229/

[marsupial]

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.

[Médinoc]

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.

[Pierre GIRARD]

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.

[Médinoc]

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...

[Pierre GIRARD]

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.